Using Wireshark, I captured a stream of UDP packets from a smart device. A few details:
The device directly sends these packets to my cellular device, communicating with an app. There's no cloud service in between.
The device is sending video/audio stream, but I'm unsure of the protocol since there is no header beyond raw UDP. I have tried decoding it as RTP, but again, due to the lack of a header, Wireshark isn't able to interpret it as such.
The stream is unencrypted; when I cover the camera and muffle the microphone, the data contains a lot of b0s.
What are some things I can check to find out what protocol this stream is encoded in?
Related
I am monitoring USB traffic with Wireshark in the interface XHC2. However, the payload of all USB packets is all-zero. The packet's length is correct, but the packet's payload is all zero. It does not matter which device, which packet or whichever. It is always zero. Obviously, this is not the reality, since the devices work properly and lot of information is displayed via lsusb.
My guess is that the XHC interface is setting the payload to 0 before delivering to upper layers, but I do not know if it is intentionally, a bug, kernel issue, my fault or something related with Wireshark.
I also tried tcpdump -i XHC2 and the saved pcap file is the same.
Additional info:
Mac Mini M1 with Big Sur
Wireshark ARM 3.6
SIP disabled
It's unlikely to be related to Wireshark, given that it happened when you captured with tcpdump as well.
You should file an issue on Apple's Feedback Assistant.
Is my observation correct that RTP/RTCP packets from a webRTC stream cannot be analyzed in Wireshark running on the same desktop to analyze RTP packets because the browser would have encrypted them using DTLS/SRTP?
I know there are some browser APIs to help but is there any other approach?
libpcap if used to write some tool will probably have the same problem.
Firefox has support for dumping the decrypted RTP/RTCP packets into the log files, described here. Chrome does not have something similar unfortunately.
If you use a server, some of them like Janus have the ability to generate similar dumps, see here
I'm trying to sent some audio stream from my browser to some server(udp, also try websockets).
I'm recording audio stream with webrtc , but I have problems with transmitting data from a nodeJS client to the my server.
Any idea? is it possible to send audio stream to the server using webrtc(openwebrtc)?
To get audio from the browser to the server, you have a few different possibilities.
Web Sockets
Simply send the audio data over a binary web socket to your server. You can use the Web Audio API with a ScriptProcessorNode to capture raw PCM and send it losslessly. Or, you can use the MediaRecorder to record the MediaStream and encode it with a codec like Opus, which you can then stream over the Web Socket.
There is a sample for doing this with video over on Facebook's GitHub repo. Streaming audio only is conceptually the same thing, so you should be able to adapt the example.
HTTP (future)
In the near future, you'll be able to use a WritableStream as the request body with the Fetch API, allowing you to make a normal HTTP PUT with a stream source from a browser. This is essentially the same as what you would do with a Web Socket, just without the Web Socket layer.
WebRTC (data channel)
With a WebRTC connection and the server as a "peer", you can open a data channel and send that exact same PCM or encoded audio that you would have sent over Web Sockets or HTTP.
There's a ton of complexity added to this with no real benefit. Don't use this method.
WebRTC (media streams)
WebRTC calls support direct handling of MediaStreams. You can attach a stream and let the WebRTC stack take care of negotiating a codec, adapting for bandwidth changes, dropping data that doesn't arrive, maintaining synchronization, and negotiating connectivity around restrictive firewall environments. While this makes things easier on the surface, that's a lot of complexity as well. There aren't any packages for Node.js that expose the MediaStreams to you, so you're stuck dealing with other software... none of it as easy to integrate as it could be.
Most folks going this route will execute gstreamer as an RTP server to handle the media component. I'm not convinced this is the best way, but it's the best way I know of at the moment.
Currently, I'm using open source code from OBS multiplatform for my video streaming application. But OBS uses RTMP for streaming, which only works on TCP. I want to use UDP since this is a live streaming scenario where I don't desire latency.
What is the best way to move to UDP? I read that protocols like RTP support UDP. Is this the best option to use? How about writing a simple UDP socket code to send and receive video data? Please guide.
The reason for trying to move to UDP is to ensure minimum latency between client and server. I'm looking for a quickest way to move to a udp based streaming than the current RTMP which uses TCP. I'm not very experienced in networking related coding. Will a simple socket program suffice to stream a video data continuously or should I implement a protocol like RTP? Or any other alternative? Ultimately, streaming should be smooth with minimum latency.
I'm testing Audio/Video P2P connection between mobile devices.
Studying WebRTC, I've noticed NAT traversal(uses STUN server) and UDP-hole-punching is the key to make P2P possible.
On the other hand, I've noticed HLS(HttpLiveStreaming) on iOS devices is very optimized for A/V live streaming, and widely available even with Android4.x(3.x unstable)
So, here is my question if I use HLS for mobile P2P:
a) HLS is a protocol on TCP(HTTP) not UDP, so isn't there a performance drawback?
See: TCP vs UDP on video stream
b) How about NAT traversal? Will it be easier since HLS is HTTP(port:80)?
I have read wikipedia http://en.wikipedia.org/wiki/HTTP_Live_Streaming
Since its requests use only standard HTTP transactions, HTTP Live
Streaming is capable of traversing any firewall or proxy server that
lets through standard HTTP traffic, unlike UDP-based protocols such as
RTP. This also allows content to be delivered over widely available
CDNs.
c) How about android device compatibility? Is there a lot of problems to invoke StreamingLive distribution?
Thanks.
The reason why firewalls are not an issue for HLS is that it's a client-server protocol where all requests are done via HTTP on port 80. If you are implementing a P2P application, you won't be able to attach it to a port below 1024 unless you have root privileges.
This means that exchanging data via HLS (port 80) won't work for P2P. Unless you have a translation server in the middle, which defeats the purpose of P2P.
Comparing HTTP Live Streaming to P2P video streaming over UDP/RTP is almost like comparing apples and oranges. More like oranges and tangerines... read on.
HTTP Live Streaming was designed as client-server protocol without P2P or NAT traversal consideration. The idea being that the streaming server is already over HTTP/TCP and accessible from the public internet as if it was just an ordinary web server. The key features of HLS is its ability to dynamically switch the bitrate based on how well the client receives the stream. If the client connection to the server hiccups trying to stream down a 1080p video, it can transparently switch to sending a lower bitrate video (and likely switch back to streaming at higher bitrate if network conditions improve). Good example: Netflix.
WebRTC and ICE were designed to stream real time video bidirectionally between devices that might both behind NATs. As such, traversing a NAT through UDP is much easier than TCP. UDP lends itself to real-time (less latency) than TCP. Most video-chat clients (ala Skype) have dynamic bandwidth adjustments built in to their codecs and protocols to achieve something similar to what HLS does.
I suppose you could combine TCP NAT traveral and HLS together. Doing HLS over UDP implies that you build a TCP like reliability layer on top of your UDP stream.
Hope this helps
http://www.garymcgath.com/streamingprotocols.html
HTTP Live Streaming
The new trend in streaming is the use of HTTP with protocols that
support adaptive bitrates. This is theoretically a bad fit, as HTTP
with TCP/IP is designed for reliable delivery rather than keeping up a
steady flow, but with the prevalence of high-speed connections these
days it doesn't matter so much. Apple's entry is HTTP Live Streaming,
aka HLS or Cupertino streaming. It was developed by Apple for iOS and
isn't widely supported outside of Apple's products. Long Tail Video
provides a testing page to determine whether a browser supports HLS.
Its specification is available as an Internet Draft. The draft
contains proprietary material, and publishing derivative works is
prohibited.
The only playlist format allowed is M3U Extended (.m3u or .m3u8), but the format of the streams is restricted only by the implementation.
I could achieve P2P on top of HLS using WebRTC on a Android with a Mozilla Firefox browser and two others desktop browsers (Chrome and Firefox) on the same swarm.
Here's a screenshot of a presentation that I've made on the University: https://www.dropbox.com/s/zyfgs4o8al9ovd0/Screenshot%202014-07-17%2019.58.15.png
This screenshot was made by acessing http://bem.tv/demo.html.
If you want to know more about, this is my masters project and I'm publishing my advances on http://bem.tv and http://github.com/bemtv.