I have an incoming RTP stream on one computer (called, "server1") connected to another computer (called, "client1") over a LAN. However, the Ethernet header (MACDA/MACSA), IPv4 header (IPDA/IPSA), and UDP header (dstport/srcport) for all of the packets belong to another network and different computers. Furthermore, the client computer did not request or initiate the stream. It is "just there"! :)
I am not interested in controlling (stopping, starting, track jumping, etc.) the stream. I just want to see and hear it in a VLC client.
I have complete control over the packets, so that I can change all of the header info as it leaves the server.
How can I modify the packets, so that VLC will play them? I can point VLC at my server, and I can mangle the packets, so they appear to have been sourced by the server and destined for the client. But, I do not know the destination port opened by VLC on the client. What am I missing?
Thanks!
I may not have the best answer, but here's a little something that might help...
"I was trying vlc player and I says, Sdp required, cannot play rtp with dynamic payload type. Is it possible to play rtp with dynamic payload type by other player, or somehow create sdp protocol using libjitsi. Thanks a lot."
Reply:
"You need an SDP description.
I found on stackoverflow a minimal SDP description. Minimum SDP for making a H264 RTP stream?.
You can try to replace the IP address, port number and payload type by the ones you’re using, maybe that’ll work."
Related
Hey Stackoverflow community :)
Im looking into making a camera stream video from a an RC device into a computer using wifi.
After considering all of the options I had Im left with two:
use UDP to transfer video in packets
use packet injection and packet sniffing on the receiving device.
I was wondering what are the pros and cons of each method (for that specific purpose of video transmission)?
after looking around I found many implementations for both ways but nowhere have they specified why one is better than the other.
few things that I have not mentioned:
I know UDP does not have error correction which can make the video weird- I dont care about the quality of the video as long as it will be recognizeable.
I dont want to use connection based protocol (TPC, etc)- I dont want to wait for handshake when I get disconnected.
thanks :)
I'm trying to do a similar thing. My take on this is basically when you use the wifi cards in monitor mode (i.e. using packet sniffing/injection) you don't actually need to be connected to that network. Typically, you still need to be connected to an Access point as a client then you can communicate using UDP through that connection. But, in this case, the UDP messages are routed to the Wifi cards and the packets are injected out without being associated with any client. Then, any 'client' just has to sniff or listen on that same channel to get the transmission. So the benefit is not only does UDP not check for lost frames/etc, but also in this case you don't need to be connected to the network to get the packets.
In my case, this is preferable, since basically you will need to connect to the AP in the former case and that would require more capable hardware on the receiver side typically (more range is needed for the association part since you need to send messages back over TCP essentially to get it connected).
FYI here are the links/repos I am using and it also is a reference to what I am talking about
https://docs.px4.io/master/en/tutorials/video_streaming_wifi_broadcast.html
https://github.com/svpcom/wifibroadcast
I am using an off the shelf 'solution' in the short term, the Accsoon Cineye Air, which basically transmits HDMI 300ft line of sight over WiFi. You need an android phone to receive it, and basically I'm using the Vysor application (paid version is $40) to mirror the screen to my desktop. It works, but the latency is still more than I want : 60ms at least from the cineeye, so you can drive it around but its not as quick as DJI which is around 30-40ms ), which is my goal.
I have a .pcap file captured from my network adapter using Wireshark. I'm trying to analyses its contents using a python script. The problem is that I can't find anything specific to RTP packets in the Wireshark. Note that I don't want to use the port numbers to detect the protocol. I want to inspect the raw data and detect the RTP protocol packets. Is there any way to do that? I mean is there anything special in RTP packets that I can use that statistic to detect RTP packets among a lot of other protocols packets?
Wireshark analyses the VOIP signaling messages to know which UPD ports are being used for RTP. Apart from the version number bits (and thats really too short), the RTP packets themselves don't have much you can use to identify them by themselves.
There is a setting in wireshark that allows RTP detection without signaling:
Edit menu -> Preferences -> Protocols -> RTP -> Allow subdissector to reassemble RTP streams
I need to analyze the wireless traffic occurring in Ch 1 of 802.11g. I have captured all the traffic logs using NETMON as test.cap file.
Q: How can extract the information using tshark to suitable format so that it can be used for further post processing?
I have captured all the activity in Ch11 but in wireshark it shows only 802.11 in protocol.
That usually means "the traffic is encrypted and Wireshark doesn't have enough information to decrypt it"; it does represent activity.
So if you're capturing on channel 11, an I/O graph in Wireshark, rather than anything extracted using TShark and further processed, should suffice to show the level of activity on that channel. You'd only have to dissect it if you want to see what type of traffic, at a higher level, that activity is, but it sounds as if you just care about activity, no matter what the packets are.
I'm using cocoaAsync to handle udp communication.
When i use the sendData API of cocoaAsync ,I'm sure sendto is success,from the log. But I can't see any output data from Wireshark .
This is not 100% reproducible, but very probably.
I can't figure out what could be the problem.
Thanks very much for any tips.
If you are sure that you are sending the packets right then following can be possibilites,
If you are sending and receiving on same machine then it is possible that your Wireshark do not capture. Try sending to some different destination than your machine.
Also there can be multiple network interfaces on your machine (e.g: eth0, eth1 etc...) for Wifi and Network-Card. Please make sure you are capturing packets on the right interface. You can select interface when you press the Capture button on Wireshark.
I hope this helps.
To explain what I would like to get, here's an example.
Let's say, we have a PC with one NIC. It has single IP address 172.16.0.1.
Using VLC, we start a udp stream to 172.16.0.1:1234, then launch another copy of VLC and connect to udp://#172.16.0.1:1234. Now we'll see our video streaming.
If you run sniffer, you will see packets from 172.16.0.1:some_random_port to 172.16.0.1:1234 on loopback. There's no trafic on our NIC.
What I want to do is to stream and receive udp in the same computer, like VLC does it. But the main problem is that pcap can only pcap_open() a real device, it can't work with loopback.
Is it possible to solve that problem?
P.S. I'm using Windows and WinPcap, unlike Linux version, it can send packets.
If you just want to send and receive UDP packets, I would suggest just using regular Winsock sockets, just as you'd use regular sockets on UN*X; using WinPcap requires that you re-implement IP and UDP, and won't let you send to another socket on the same machine under Windows (or on at least some versions of UN*X, either).
If you want to watch the traffic you're sending, unfortunately WinPcap won't help, as it relies on packets being sent out and received from NDIS (its driver plugs into NDIS), and that doesn't happen for packets sent from one socket on a machine to another socket on the same machine.
(Note, BTW, that libpcap can send packets on Linux and *BSD and Mac OS X and Solaris and Digital/Tru64 UNIX, for example, and has been able to do so for several years; older versions of libpcap didn't support it, but the versions available for the past few years can. However, as per my first paragraph, it would not make sense to use libpcap to send and receive regular UDP packets on those OSes, just as it makes no sense to use WinPcap for that purpose on Windows.)