I've developed an app which sends RTP packets to a local ip client. So the client has to listen on the specified port (rtp://:#portnumber, on VLC) to play the streamed data. Right now i'm going to develop the code needed to create the SDP file needed to start streaming.
My doubt is, how to send this file to the client? At the beginning of the RTP stream?
Really n00b at this point. Any help will be useful.
Thanks
VLC specifically supports RTSP, HTTP, SAP protocols for establishing session and communication. And of course the local file system (file://)
so basically you can call vlc in some manner like this (I cannot test it but should be like this):
vlc file://path/to/sdp-file
or
vlc rtsp://server-path:port/sdpfile.sdp
and so on
Aside from storing the SDP file in the local system, perhaps HTTP would be easiest if you have up and running http server on your server machine.
Related
I need to do some validation testing of a new feed handler I have made. I have some pcap data that I captured from the production network and I would like to have my development feed handler connect to the "replay" of this data and compare the results.
My pcap:
I have a prod application that connects to a data feed, a TCP connection to an external server lets call assume this is 123.456.789.1:1234. This external sever then sends data to my application there is almost no client to server communication the server just sends the client data until the client drops. I have a pcap of all the packets sent to and from port 1234. I got this pcap by mirroring the production port (SPAN) on the switch and attaching tcpdump to an interface plugged in to the mirrored network port. When I look at the PCAP in wireshark it has all the data I would expect.
My problem:
I am in no way a network engineer and I am unsure how I can use this pcap to test my application. What I would like to do is "replay" this stream form the pcap and connect to it with my development application to validate that the data is being handled the same was it was on the prod connection.
I would like to some how "replay" the data sent from 123.456.789.1:12344 on 127.0.0.1:1234 and then connect to 127.0.0.1:1234 with my dev application. I looked at tcpreplay but from the documents I can not seem to figure out if it can do this, I get the feeling that they do not handle the tcp session data, and I could do this if it was a UDP stream, but tcpreplay can not act as the external server. Did I read this wrong or is there another tool that will let me do this?
thanks!
You may want to use netcat if you just want to throw some data back at your tool, and you don't care about what the tool sends.
You would do this by extracting the raw data sent by your tool from the pcap file (this tool may be helpful) and then piping that into netcat.
I'm trying to build RTP media projector for only audio streams.
A user will create a session with the server and possibly broadcast audio stream.
The server will send to the user audio streams of all the other active users.
Can the server send media from a single port or does it need to be able to use a range of ports for sending? (I know it needs to listen to ports 1024 - 65535).
Does the server need to use ICE or can it just respond to the SDP request right away?
How does RTCP works in this scenario? Does the server sends quality of service feedback in the name of clients or acts as a client and sends feedback for himself?
What does the server do with quality of service feedback from the clients?
Does the server need to do something with the media packets like changing timestamps or just deliver them as is, assuming all clients are using the G.711 codec?
Thanks
The MCU can use a single port if it is the passive side in the peer-to-peer connection or a separate port for each session if it is the active side.
The MCU can act as a Translator and just forward RTCP packets from clients but this might result with high bandwidth usage. A more complicated MCU can parse RTCP packets and generate RTCP reports from this info.
The MCU need to decrypt and re-encrypt the RTP packets but as long as all the participants are using the same codec, there is no need for transcoding.
The info can be found in the RTP rfc
http://www.ietf.org/rfc/rfc3550.txt
Established: I am currently streaming data packets(.mp3 files) from source(server) to sink(client A) using gstreamer over RTP. This thing is pretty easy and I am successfully able to stream music over a network from server to device.
Requirement: Now, I want to retransmit the data packets in real time(or atleast as close to real time as possible) from the client A to say any other client B . Hence the control would still remain with client A and only the music would now be actually streaming with client B.
What is the most optimum way to do such a thing.
Assuming you want to quickly try this. The ideal way is to setup a rtsp server on client A which can forward client B data. If you want to do it your way here is one way to do it:
If you have a player in client B which can play a rtp stream given a sdp file this is what you can do:
Create a copy of the sdp you get in client A. Give it to client B via some path. [Say tcp socket that both agree to communicate upon]
Stream a copy of what you get in client A to client B as well.
You need to change port numbers in sdp to be the one available at client B [This what RTSP negotiation does]. If the client B can tell client A the port number before it gets the SDP, great, you can then set the port number in the sdp correctly, give it to client B and then send a copy of he stream to client B. you are done.
you also uset RTP over TCP.
So it would be easy for you, as no changes require at RTP level.
You need to pass packet to RTSP instead of sending directly over UDP socket.
everything will be handle by RTSP.
If you are using RTP as a stand alone ,accoeding to rfc 3550 , its not a part of RTP
Still you wan't to do so, then you are not following standard way of RTP implementation.
I've compiled with VS the live555 source code, and it works just fine if I try to stream locally a file
e.g.
Command Line:
live555.exe myfile.mp3
VLC Connection String
rtsp://169.254.1.231:8554/myfile.mp3
but if I try to stream it over the internet, VLC communicates with live555, but live555 won't send data to him
Command Line
live555.exe myfile.mp3
VLC Connection String
rtsp://80.223.43.123:8554/myfile.mp3
I've already forwarded the 8554 port (both tcp/udp) and tried to disable my firewall but this doesn't solve.
How is that?
To troubleshoot:
Are you streaming RTP over RTSP: have you checked the "Use RTP over RTSP (TCP)" option in VLC? You can check this in VLC under the preferences: input/codecs->Demuxers->RTP/RTSP. You can try to see if this solves the problem in which case it could be that UDP is blocked.
You speak of forwarding. Do you mean port forwarding from one machine to the RTSP server? if so-> if you are not doing RTP over RTSP, then you would also need to forward the ports for the media which is not the same as the RTSP port (554 or 8554). These ports are exchanged during the RTSP SETUP. If you do RTP over RTSP the media is interleaved over 554 or 8554 and you don't have to worry about this.
Also, another good debugging tool is the live555 openRTSP application. You can run it from the command line and specify "-t" for RTP over RTSP, which is basically what the VLC option does. You can specify "-T" for HTTP tunneling, etc and it allows you to write captured media packets to file, etc.
I am writing a RTSP client in Android. I am able to receive the Responses for all the requests
i.e.,
DESCRIBE it sends back the 200 OK
SETUP with transport: RTP/AVP:unicast:client_port=4568:4569 got the 200 OK Message back
Sent PLAY, and got the OK Message
After that how to get the audio and video frames?
I have searched on blogs, but all say to listen at client_port but I am not receiving any packets.
Please let me know am I doing correctly.
You may or may not know this, but Android has built in support for RTSP using the VideoView.
http://developer.android.com/reference/android/widget/VideoView.html
This may cut down on your development time...or it may be totally useless if you're trying to roll your own RTSP stack.
RTSP is only used to start the streaming. It gives you an SDP description of the real streams. You have to manage an RTCP connection and a RTP connection per channel (audio / video). The ports to use are the "client_port" ones.
It is pretty complex to code a RTSP/RTCP/RTP stack from scratch. You can have a look at the live555 library that implement such a stack in c++.
Put a sniffer on the network, you should see UDP packet with destination port 4568 targeted at your IP address.
With a decent sniffer, you will be able to see the rtsp dialog. Maybe you are missing something in the answers
You should also check the content of the SETUP response, to see if the port you requested were accepted.
Things to check :
Listening in UDP.
Firewall rules.
Range of the play request : Don't specify any to be sure the server will be playing something.
If you are behind a router or firewall, you probably won't receive anything, because your router / firewall don't know what to do with incoming UDP packets
Try first with a local Darwin Streaming server installed within your LAN.that way Firewall wont matter.Streaming will work.
If you want to try from external server then:
1) Check the client_ports mentioned in the SERVER response,some servers suggest different ports from the one requested.you have to use the ports suggested by server.
2) If the ports are correct, then you can send 64byte empty packets from each of the UDP ports to the server(called "door openers").
3) If the above two don't fix it, check the server side logs.The server might be closing the UDP ports.