我很难让 gstreamer 将 UDP 数据包发送到我们的 UWP 应用程序（从同一台计算机上的进程）。该应用程序的早期版本已成功使用 webrtc 来执行此操作。
据我从here（搜索“数据报”）了解到，UWP 环境将阻止源自同一计算机上进程的任何传入 UDP 流量。然而，使用wireshark告诉我，当客户端显示来自该服务器的视频时，有大量来自我们服务器的UDP流量，例如：
No. Time Source Destination Protocol Length Info
3858 170.387279 172.28.176.1 172.28.176.1 UDP 1021 62939 → 62943 Len=989
3859 170.392223 172.28.176.1 172.28.176.1 UDP 1021 62939 → 62943 Len=989
3860 170.398190 172.28.176.1 172.28.176.1 UDP 1021 62939 → 62943 Len=989
3861 170.407987 172.28.176.1 172.28.176.1 UDP 82 62943 → 62939 Len=50
3864 170.465804 10.90.15.232 10.90.15.232 STUN 128 Binding Request user: tM+9:f0ml
3865 170.465988 10.90.15.232 10.90.15.232 STUN 96 Binding Success Response XOR-MAPPED-ADDRESS: 10.90.15.232:62944
3872 170.478672 10.90.15.232 10.90.15.232 STUN 128 Binding Request user: f0ml:tM+9
3873 170.478784 10.90.15.232 10.90.15.232 STUN 96 Binding Success Response XOR-MAPPED-ADDRESS: 10.90.15.232:62940
3880 170.520962 172.28.176.1 172.28.176.1 UDP 1032 62939 → 62943 Len=1000
3881 170.522957 172.28.176.1 172.28.176.1 UDP 1032 62939 → 62943 Len=1000
3882 170.524946 172.28.176.1 172.28.176.1 UDP 1032 62939 → 62943 Len=1000
3883 170.526933 172.28.176.1 172.28.176.1 UDP 1032 62939 → 62943 Len=1000
3884 170.528002 172.28.176.1 172.28.176.1 UDP 74 62943 → 62939 Len=42
3885 170.530964 172.28.176.1 172.28.176.1 UDP 1033 62939 → 62943 Len=1001
3886 170.531973 172.28.176.1 172.28.176.1 UDP 1033 62939 → 62943 Len=1001
3887 170.533888 172.28.176.1 172.28.176.1 UDP 1022 62939 → 62943 Len=990
3888 170.536886 172.28.176.1 172.28.176.1 UDP 1022 62939 → 62943 Len=990
3889 170.543962 172.28.176.1 172.28.176.1 UDP 102 62943 → 62939 Len=70
3890 170.545020 172.28.176.1 172.28.176.1 UDP 102 62939 → 62943 Len=70
但是如果我使用这个管道来生成视频：
./gst-launch-1.0 -v videotestsrc ! video/x-raw,media=video,format=BGR,width=320,height=240,framerate=30/1 ! videoconvert ! rtpvrawpay ! udpsink host="172.28.176.1" port="5000"
当它在使用此管道运行我的客户端的同一台计算机上运行时，我什么也得不到：
udpsrc port=5000 ! application/x-rtp,media=video,encoding-name=RAW,sampling=BGR,width=(string)320,height=(string)240,clock-rate=90000,depth=(string)8 ! rtpvrawdepay ! videoconvert ! queue ! d3d11videosink
这种情况下的wireshark输出是
No. Time Source Destination Protocol Length Info
522 38.046343 172.28.176.1 172.28.176.1 UDP 1432 58998 → 5000 Len=1400
523 38.046632 172.28.176.1 172.28.176.1 UDP 1432 58998 → 5000 Len=1400
524 38.046816 172.28.176.1 172.28.176.1 UDP 1432 58998 → 5000 Len=1400
525 38.046972 172.28.176.1 172.28.176.1 UDP 1432 58998 → 5000 Len=1400
526 38.047108 172.28.176.1 172.28.176.1 UDP 1432 58998 → 5000 Len=1400
527 38.047239 172.28.176.1 172.28.176.1 UDP 1432 58998 → 5000 Len=1400
528 38.047367 172.28.176.1 172.28.176.1 UDP 1426 58998 → 5000 Len=1394
529 38.047510 172.28.176.1 172.28.176.1 UDP 1432 58998 → 5000 Len=1400
530 38.047637 172.28.176.1 172.28.176.1 UDP 1432 58998 → 5000 Len=1400
531 38.047763 172.28.176.1 172.28.176.1 UDP 1432 58998 → 5000 Len=1400
但是，如果从我们网络上的另一台计算机运行相同的 gst-launch 命令，我确实会在客户端中获取视频，这似乎证实了上面 MS 文档中的声明。
所以，显然 webrtc 代码正在做一些事情，让流量看起来好像来自我们机器之外的某个地方。应该注意的是，即使我们的机器没有连接到网络，只要我们运行虚拟交换机（使用 HyperV），webrtc 解决方案就可以工作。
webrtc 正在设法实现我们没有做的什么样的黑魔法？