How to achieve visibility and meeting join for my appHostedMediaConfig bot

Question

How to achieve visibility and meeting join for my appHostedMediaConfig bot

AshJaffer 0

I'm developing a Teams bot using the Microsoft Graph Communications SDK (C#) with application-hosted media. The bot successfully joins meetings and can receive video (VideoReceiveStatusChanged fires), but:

Bot missing from participant roster (used to appear, broke after code changes)
VideoSendStatusChanged event never fires (prevents video tile from appearing)
Bot sends 300+ H.264 frames successfully but Teams doesn't recognize it as video participant

Environment:

SDK: Microsoft.Skype.Bots.Media v1.31.0.225 (latest)
Framework: .NET 8.0
Deployment: Windows VM, production certificates
Manifest: supportsCalling: true, supportsVideo: true

Current Implementation:

VideoSocket Configuration:

csharp

var videoSocketSettings = new VideoSocketSettings
{
    StreamDirections = StreamDirection.Sendrecv,
    SupportedSendVideoFormats = new List<VideoFormat>
    {
        VideoFormat.H264_320x180_15Fps,
        VideoFormat.H264_424x240_15Fps, 
        VideoFormat.H264_640x360_30Fps,
        VideoFormat.H264_1280x720_30Fps,
        VideoFormat.H264_1920x1080_30Fps
    },
    ReceiveColorFormat = VideoColorFormat.H264,
    MaxConcurrentSendStreams = 1
};

Meeting Join:

ILocalMediaSession mediaSession = _communicationsClient.CreateMediaSession(audioSocketSettings, videoSocketSettings);
var joinMeetingParams = new JoinMeetingParameters(chatInfo, meetingInfo, mediaSession);
ICall createdCall = await _communicationsClient.Calls().AddAsync(joinMeetingParams);

Expected vs Actual Behavior:

Expected:

Bot appears in Teams participant roster
VideoSendStatusChanged fires with MediaSendStatus.Active
Video tile appears in meeting gallery after sending H.264 frames

Actual:

✅ Meeting join succeeds (Successfully initiated meeting join via SDK)
✅ VideoReceiveStatusChanged fires (MediaReceiveStatus=Active)
✅ H.264 frames sent successfully (330+ frames logged)
❌ VideoSendStatusChanged NEVER fires
❌ Bot missing from participant roster
❌ No video tile appears

Generated Media Config Analysis:

POST request shows:

json

"videoSinkEncodingFormats":["H264"]  // ✅ Present (receive)
// Missing: "videoSourceEncodingFormats" - could this be the issue?

What We've Tried:

Verified all Graph API permissions (admin consented)
Confirmed bot manifest has correct properties
Implemented bypass: force sending frames without waiting for VideoSendStatusChanged
Checked SDK version (77 days old - within 90 day limit)
Verified certificates and network connectivity

Specific Questions:

Why would VideoSendStatusChanged never fire despite successful join and proper H.264 config?
Why is videoSourceEncodingFormats missing from the generated media config blob?
What's the difference between "connected" and "participant" status in Teams?
Any specific VideoSocket configuration required for participant roster visibility?

Sample Logs:

[23:07:55] ✅ Successfully initiated meeting join via SDK
[23:07:56] 📹 VideoReceiveStatusChanged: MediaReceiveStatus=Active  
[23:07:56] 🎥 Starting to send video frames at 1280x720 @ 30fps
[23:07:56] ✅ Frame 0 sent to VideoSocket (port 3480 expected)
[23:08:08] 🎥 Sent 300 video frames (10s) for call
// VideoSendStatusChanged NEVER logged

Any insights on what could cause Teams to not recognize the bot as a video sender despite successful frame transmission? Are there specific requirements for participant roster viI'm developing a Teams bot using the Microsoft Graph Communications SDK (C#) with application-hosted media. The bot successfully joins meetings and can receive video (VideoReceiveStatusChanged fires), but:

Bot missing from participant roster (used to appear, broke after code changes)
VideoSendStatusChanged event never fires (prevents video tile from appearing)
Bot sends 300+ H.264 frames successfully but Teams doesn't recognize it as video participant

Environment:

SDK: Microsoft.Skype.Bots.Media v1.31.0.225 (latest)
Framework: .NET 8.0
Deployment: Windows VM, production certificates
Manifest: supportsCalling: true, supportsVideo: true

Current Implementation:

VideoSocket Configuration:

var videoSocketSettings = new VideoSocketSettings
{
    StreamDirections = StreamDirection.Sendrecv,
    SupportedSendVideoFormats = new List<VideoFormat>
    {
        VideoFormat.H264_320x180_15Fps,
        VideoFormat.H264_424x240_15Fps, 
        VideoFormat.H264_640x360_30Fps,
        VideoFormat.H264_1280x720_30Fps,
        VideoFormat.H264_1920x1080_30Fps
    },
    ReceiveColorFormat = VideoColorFormat.H264,
    MaxConcurrentSendStreams = 1
};

Meeting Join:

ILocalMediaSession mediaSession = _communicationsClient.CreateMediaSession(audioSocketSettings, videoSocketSettings);
var joinMeetingParams = new JoinMeetingParameters(chatInfo, meetingInfo, mediaSession);
ICall createdCall = await _communicationsClient.Calls().AddAsync(joinMeetingParams);

Expected vs Actual Behavior:

Expected:

Bot appears in Teams participant roster
VideoSendStatusChanged fires with MediaSendStatus.Active
Video tile appears in meeting gallery after sending H.264 frames

Actual:

✅ Meeting join succeeds (Successfully initiated meeting join via SDK)
✅ VideoReceiveStatusChanged fires (MediaReceiveStatus=Active)
✅ H.264 frames sent successfully (330+ frames logged)
❌ VideoSendStatusChanged NEVER fires
❌ Bot missing from participant roster
❌ No video tile appears

Generated Media Config Analysis:

POST request shows:

json

"videoSinkEncodingFormats":["H264"]  // ✅ Present (receive)
// Missing: "videoSourceEncodingFormats" - could this be the issue?

What I've Tried:

Verified all Graph API permissions (admin consented)
Confirmed bot manifest has correct properties
Implemented bypass: force sending frames without waiting for VideoSendStatusChanged
Checked SDK version (77 days old - within 90 day limit)
Verified certificates and network connectivity

Specific Questions:

Why would VideoSendStatusChanged never fire despite successful join and proper H.264 config?
Why is videoSourceEncodingFormats missing from the generated media config blob?
What's the difference between "connected" and "participant" status in Teams?
Any specific VideoSocket configuration required for participant roster visibility?

Sample Logs:

[23:07:55] ✅ Successfully initiated meeting join via SDK
[23:07:56] 📹 VideoReceiveStatusChanged: MediaReceiveStatus=Active  
[23:07:56] 🎥 Starting to send video frames at 1280x720 @ 30fps
[23:07:56] ✅ Frame 0 sent to VideoSocket (port 3480 expected)
[23:08:08] 🎥 Sent 300 video frames (10s) for call
// VideoSendStatusChanged NEVER logged

Any insights on what could cause Teams to not recognize the bot as a video sender despite successful frame transmission? Are there specific requirements for participant roster visibility as opposed to just being connected?

Nivedipa-MSFT 3,731 Reputation points Microsoft External Staff Moderator

2025-08-04T06:02:58.7733333+00:00
@AshJaffer - Thanks for bringing this issue to our attention.
The absence of videoSourceEncodingFormats in your media configuration is a critical indicator — it suggests that Microsoft Teams failed to negotiate video sending capabilities during the SDP exchange. As a result, your bot is connected but not recognised as a full video participant.

Please verify the following checkpoints to ensure proper setup:

Set ParticipantInfo.Source in your join parameters.

Subscribe to events before joining the meeting.

Wait for VideoSendStatusChanged before transmitting any video frames.

Start with fewer video formats to simplify the negotiation process.

Enable detailed logging to help diagnose negotiation issues.

Confirm your bot appears in call.Resource.Participants.
AshJaffer 0 Reputation points

2025-08-04T17:00:20.0466667+00:00
@Nivedipa-MSFT Thank you for your suggestions! The bot joins meetings fine and can receive video, but VideoSendStatusChanged never fires. After digging through the logs, I noticed that videoSourceEncodingFormats is missing from the media negotiation blob, even though we're sending H.264 frames. Also The ParticipantInfo.Source property doesn't exist in the latest SDK version (1.2.0.10563). Our enhanced source field with video capability indicators isn't being applied.

I think the issue seems to be that the .NET SDK doesn't let us properly indicate that our bot can send video. The SDK automatically sets a basic source field, but we can't enhance it with video capability indicators.

We're thinking of calling the REST API directly instead of using the SDK. What properties should we include in the ParticipantInfo.Source to tell Teams "hey, this bot can send video"?

Should I be setting:

modalities: ["Audio", "Video"]?

Some kind of supportsVideo flag?

Something in the identity object?

I got all the permissions and certificates working - just need to figure out the right JSON structure so Teams knows to negotiate video sending capability with our bot.

Any insights would be super helpful! Thanks!

Update:

UPDATE: Research on ParticipantInfo.Source Property

The official Microsoft Graph API documentation I've read shows that the ParticipantInfo resource has no "Source" property. However, I can confirm the JSON payload does include a source field:

json

"source":{"@odata.type":"#microsoft.graph.participantInfo","identity":{"@odata.type":"#microsoft.graph.identitySet","application":{"displayName":"Mira Teams Bot","id":"4a1b3310-ca04-4bca-8240-cc99ac3db852"}}}

This appears to be auto-generated by the SDK based on:

CommunicationsClientBuilder display name MediaSession configuration (video sockets) RequestedModalities settings

What I've tested:

✅ RequestedModalities explicitly set to ["Audio","Video"] ✅ Video socket properly configured with H.264 formats ✅ Events attached before AddAsync() call ✅ VideoReceiveStatusChanged fires (can receive video) ❌ VideoSendStatusChanged never fires (can't send video)

The core issue remains: Teams accepts the bot for video receive but not video send.UPDATE: Research on ParticipantInfo.Source Property

Based on comprehensive research of the official Microsoft Graph API documentation, the ParticipantInfo resource has no "Source" property. However, I can confirm the JSON payload does include a source field:

json

"source":{"@odata.type":"#microsoft.graph.participantInfo","identity":{"@odata.type":"#microsoft.graph.identitySet","application":{"displayName":"Mira Teams Bot","id":"4a1b3310-ca04-4bca-8240-cc99ac3db852"}}}

This appears to be auto-generated by the SDK based on:

CommunicationsClientBuilder display name

MediaSession configuration (video sockets)

RequestedModalities settings

What I've tested:

✅ RequestedModalities explicitly set to ["Audio","Video"]

✅ Video socket properly configured with H.264 formats

✅ Events attached before AddAsync() call

✅ VideoReceiveStatusChanged fires (can receive video)

❌ VideoSendStatusChanged never fires (can't send video)

The core issue remains: Teams accepts the bot for video receive but not video send.
Nivedipa-MSFT 3,731 Reputation points Microsoft External Staff Moderator

2025-08-05T06:05:31.3366667+00:00
@AshJaffer -
The .NET SDK for Teams Calling/Meetings bots does not provide a direct way to add video capability indicators to the ParticipantInfo.Source property.

The official Microsoft Graph API documentation does not mention a Source property for ParticipantInfo, but the SDK generates it automatically based on your settings.

Video send capability is negotiated through:

The requestedModalities field, which should include both "Audio" and "Video".

Proper media session setup with video sockets that support H.264.

The bot’s identity included in the payload.

There is no official supportsVideo flag or direct video capability indicator in the payload. Teams uses the presence of video sockets and the requestedModalities array to determine video capability.

Troubleshooting Checklist:

Verify your media session setup includes a video socket with H.264 encoding.

Check that requestedModalities contains "video" (note that case sensitivity may apply).

Make sure all event handlers are attached before calling AddAsync().

Ensure your bot’s Azure AD app registration has the required permissions for Teams calling and meetings.

If using REST, replicate the payload structure created by the SDK, focusing on requestedModalities and media socket configuration. Ref Docs:
ParticipantInfo Resource Type
AshJaffer 0 Reputation points

2025-08-06T02:17:33.8266667+00:00
@Nivedipa-MSFT Thanks for your suggestions!

Your diagnosis was spot-on - we implemented the MediaBlobInjectionHandler, H.264 encoding, and now VideoSendStatusChanged fires successfully (it never fired before).However, we're still struggling with bot visibility in Teams meetings. The bot joins successfully and sends video frames, but users can't see it in the participant roster or video gallery.

We're hoping you can point us toward:

Documentation on what makes bots visible vs just "connected" in Teams meetings (where our bot can be shown in the media gallery as a tile and in the participants roster, rather than just "joining")

Whether there are known limitations with application-hosted media bots appearing in the UI

Sample code or repositories that demonstrate visible bot participation (we've looked at the microsoft-graph-comms-samples, policyRecordingBot)

Any additional Graph API calls needed beyond the standard join process

What we're seeing:

Call.Resource.Participants stays null even after 30+ seconds

Video negotiation works fine

Bot appears to be "in" the meeting technically, but invisible to participants

Is this expected behavior for application-hosted media bots, or are we missing something? We've tried various manifest configurations and permission settings (All api permissions and RCS permissions, application), but can't find clear documentation on the visibility requirements.

Any guidance on documentation, samples, or next steps would be incredibly helpful.
Nivedipa-MSFT 3,731 Reputation points Microsoft External Staff Moderator

2025-08-08T06:29:08.1166667+00:00
@AshJaffer -
Great progress on getting VideoSendStatusChanged to fire! The visibility issue you're experiencing is a common challenge with application-hosted media bots. Here's what you need to address:

Bot Visibility Requirements

Key factors that determine bot visibility in Teams meetings:

Active Media Transmission:

Bot must actively send both audio and video frames

Even sending "silence" audio packets is often required

Video frames must be continuous, not just occasional

Proper Participant Role:
- Ensure your join request specifies a proper participant role - Use `"presenter"` or `"attendee"` - avoid `"inLobby"` ```**Display Name Configuration:**

Bot needs a clear, non-empty display name

This appears in the participant roster

Required Implementation

// Ensure both audio and video are configured

var`` joinMeetingParams = new JoinMeetingParameters(chatInfo, meetingInfo, mediaSession)

{

    RequestedModalities = ``new List<Modality> { Modality.Audio, Modality.Video },

    // Specify participant role explicitly

    Source = ``new ParticipantInfo

    ``{

        Identity = ``new IdentitySet

        ``{

            Application = ``new Identity

            ``{

                DisplayName = ``"Your Bot Name",

                Id = ``"your-app-id"

            ``}

        ``}

    ``}

}``;

Critical Steps for Visibility

Send Audio Packets: Even if your bot doesn't need audio, send silence packets

// Send audio silence to maintain presence

private`` void SendAudioSilence()

{

    ``var silenceBuffer = new byte[320]; // 20ms of silence

    _audioSocket.Send``(silenceBuffer);

}

Continuous Video Transmission: Send video frames consistently

Monitor Participant Events: Track when your bot appears in the participants list

call.Participants.Updated += ``(sender, args) => {

    // Log participant changes

    ``foreach (var participant in args.AddedResources)

    ``{

        Console.WriteLine``($"Participant added: {participant.Info?.Identity?.Application?.DisplayName}");

    ``}

}``;

Troubleshooting Visibility

Check these specific areas:

Call.Resource.Participants null: This often indicates the bot hasn't properly "joined" as a participant

Audio requirement: Many scenarios require audio socket configuration even for video-only bots

Timing: Bot visibility can take 10-30 seconds after starting media transmission

Meeting type: Some meeting policies may affect bot visibility

Sample Code References

Working examples that demonstrate visible bots:

Audio Video Calling Bot - Shows visible bot implementation

Policy Recording Bot - Demonstrates participant roster appearance

Additional API Calls

Beyond the standard join, consider:

Monitor Call.Participants.Updated events

Use Call.Mute/Unmute operations to signal active participation

Track Call.State changes to ensure proper connection

Documentation References

https://learn.microsoft.com/en-us/microsoftteams/platform/bots/calls-and-meetings/requirements-considerations-application-hosted-media-bots?wt.mc_id=knowledgesearch_inproduct_azure-agent-for-github-copilot

https://learn.microsoft.com/en-us/microsoftteams/platform/bots/calls-and-meetings/real-time-media-concepts?wt.mc_id=knowledgesearch_inproduct_azure-agent-for-github-copilot

https://github.com/OfficeDev/Microsoft-Teams-Samples/tree/main/samples/bot-calling-meeting/csharp

Your answer

Nivedipa-MSFT 3,731 Reputation points Microsoft External Staff Moderator

2025-08-04T06:02:58.7733333+00:00

@AshJaffer - Thanks for bringing this issue to our attention.
The absence of videoSourceEncodingFormats in your media configuration is a critical indicator — it suggests that Microsoft Teams failed to negotiate video sending capabilities during the SDP exchange. As a result, your bot is connected but not recognised as a full video participant.

Please verify the following checkpoints to ensure proper setup:

Set ParticipantInfo.Source in your join parameters.

Subscribe to events before joining the meeting.

Wait for VideoSendStatusChanged before transmitting any video frames.

Start with fewer video formats to simplify the negotiation process.

Enable detailed logging to help diagnose negotiation issues.

Confirm your bot appears in call.Resource.Participants.
Nivedipa-MSFT 3,731 Reputation points Microsoft External Staff Moderator

2025-08-05T06:05:31.3366667+00:00

@AshJaffer -
The .NET SDK for Teams Calling/Meetings bots does not provide a direct way to add video capability indicators to the ParticipantInfo.Source property.

The official Microsoft Graph API documentation does not mention a Source property for ParticipantInfo, but the SDK generates it automatically based on your settings.

Video send capability is negotiated through:

The requestedModalities field, which should include both "Audio" and "Video".

Proper media session setup with video sockets that support H.264.

The bot’s identity included in the payload.

There is no official supportsVideo flag or direct video capability indicator in the payload. Teams uses the presence of video sockets and the requestedModalities array to determine video capability.

Troubleshooting Checklist:

Verify your media session setup includes a video socket with H.264 encoding.

Check that requestedModalities contains "video" (note that case sensitivity may apply).

Make sure all event handlers are attached before calling AddAsync().

Ensure your bot’s Azure AD app registration has the required permissions for Teams calling and meetings.

If using REST, replicate the payload structure created by the SDK, focusing on requestedModalities and media socket configuration. Ref Docs:
ParticipantInfo Resource Type
AshJaffer 0 Reputation points

2025-08-06T02:17:33.8266667+00:00

@Nivedipa-MSFT Thanks for your suggestions!

Your diagnosis was spot-on - we implemented the MediaBlobInjectionHandler, H.264 encoding, and now VideoSendStatusChanged fires successfully (it never fired before).However, we're still struggling with bot visibility in Teams meetings. The bot joins successfully and sends video frames, but users can't see it in the participant roster or video gallery.

We're hoping you can point us toward:

Documentation on what makes bots visible vs just "connected" in Teams meetings (where our bot can be shown in the media gallery as a tile and in the participants roster, rather than just "joining")

Whether there are known limitations with application-hosted media bots appearing in the UI

Sample code or repositories that demonstrate visible bot participation (we've looked at the microsoft-graph-comms-samples, policyRecordingBot)

Any additional Graph API calls needed beyond the standard join process

What we're seeing:

Call.Resource.Participants stays null even after 30+ seconds

Video negotiation works fine

Bot appears to be "in" the meeting technically, but invisible to participants

Is this expected behavior for application-hosted media bots, or are we missing something? We've tried various manifest configurations and permission settings (All api permissions and RCS permissions, application), but can't find clear documentation on the visibility requirements.

Any guidance on documentation, samples, or next steps would be incredibly helpful.

Share via

How to achieve visibility and meeting join for my appHostedMediaConfig bot

Your answer