No video in 1:1 calls between an application-hosted media bot and the Teams web client (the video section of the call setup is rejected)

未关闭
  • 哪里不对？
#877 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
42/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
领域
audio-video-rtc

调研方向

Start by reviewing the ICallCollection.AddAsync call setup and the reported SDP offer and answer, comparing the web-client negotiation with the desktop-client case. The issue names no source files or tests, so first locate the media-call negotiation path in the samples and check whether the video section is rejected there. Done means identifying why video is rejected and confirming video works in the described 1:1 web-client call.

由索引模型根据 Issue 内容生成。

描述

Description

An application-hosted media bot doing two-way video in 1:1 calls gets video with the Teams desktop client (Windows), but no video in either direction with the Teams web client. Audio works in both cases. This happens both when the bot calls the user and when the user calls the bot.

Environment

  • Microsoft.Skype.Bots.Media 1.33.0.258-preview
  • Microsoft.Graph.Communications.Calls.Media 1.2.0.18736
  • Teams web client on Edge 155 (Chromium) at teams.cloud.microsoft
  • Teams desktop client (Windows), used for comparison

Setup

  • One video socket: StreamDirection.Sendrecv, ReceiveColorFormat = VideoColorFormat.H264, H.264 send formats, MaxConcurrentSendStreams = 1.
  • Outgoing calls are created with ICallCollection.AddAsync(call, localMediaSession, ...). The resulting call resource has requestedModalities: [audio, video].
  • The configuration is the same for both clients.

Steps to reproduce

  1. The bot places a 1:1 call to a Teams user.
  2. The user answers in the Teams web client.
  3. Repeat, answering in the Teams desktop client.

Expected

The same video behavior as with the desktop client.

Actual: events raised on the bot's IVideoSocket

Event Desktop client Web client
VideoReceiveStatusChanged → Active yes never
VideoSendStatusChanged → Inactive yes yes
VideoSendStatusChanged → Active yes never
VideoKeyFrameNeeded yes never

When the web client user calls the bot, the video socket raises no events at all.

SDP captured in the browser (edge://webrtc-internals)

  1. The offer the web client receives from Teams has audio only, although the bot asked for audio and video:

    a=group:BUNDLE 1
m=audio 50870 UDP/TLS/RTP/SAVPF 108 104 9 103 111 18 0 8 97 101 13 120

  2. The web client then adds a video section and sends a new offer. It includes standard H.264 (e.g. profile-level-id=42e01f;packetization-mode=1) and AV1:

    m=video 9 UDP/TLS/RTP/SAVPF 102 125 124 114 116 39 118 45 ...
a=sendrecv
a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f

  3. Teams' answer rejects the video section (port 0):

    m=video 0 UDP/TLS/RTP/SAVPF 36
a=inactive

  4. The web client tries to add video a second time and is rejected again in the same way.

Even receive-only video is rejected, so the bot never gets a video stream.

Call IDs and timestamps can be shared on request.

主要语言
没有语言数据
星标
252
派生
276
30 天内没有已合并 PR

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

microsoftgraph/microsoft-graph-comms-samples 的其他 Issue

查看 microsoftgraph/microsoft-graph-comms-samples 的全部 Issue

相似的 Issue

更多 Audio/Video & RTC Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。