I'm having great difficulty in getting gstreamer to send UDP packets to our UWP application (from a process on the same machine). A previous version of the application is successfully using webrtc to do this.
As I understand from here (search for "datagram") the UWP environment will block any incoming UDP traffic originating from a process on the same machine. Yet using wireshark shows me that there is plenty of UDP traffic coming from our server when the client is displaying video originating from that server, such as:
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
Yet if I use this pipeline to generate video:
./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"
I get nothing when it runs on the same machine that is running my client using this pipeline:
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
The wireshark output in such a case is
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
However, if the same gst-launch command is run from another machine on our network, I do get video in the client, which seems to confirm the statement in the MS doc above.
So, clearly the webrtc code is doing something to make it appear as if the traffic is coming from somewhere not on our machine. It should be noted that the webrtc solution works even if our machine is not connected to a network, as long as we're running a virtual switch (using HyperV).
What sort of black magic is webrtc managing to pull off that we're not doing?
