I'm developing a RTSP Server and UDP works fine, but there's 1 issue when it's goes to TCP which is the VLC only can view streaming about 30 minutes, from the packet I see that I didn't response the RTSP GET_PARAMETER command, is this command matters and what will happen is I don't response this command?
According to the specification, GET_PARAMETER is optional for servers and clients to implement.
Related
I have a simple application in c# that opens an RTSP session and sends the appropriate commands like DESCRIBE, SETUP, etc to control an RTP data stream.
My questions is this: does the TCP session (for the RTSP communication) have to stay open while streaming the data over RTP? Without going into details as to why, I'd like to be able to close the RTSP session after the RTP streaming is setup.
RFC 7826 Real-Time Streaming Protocol Version 2.0
A persistent connection is RECOMMENDED to be used for all
transactions between the server and client, including messages for
multiple RTSP sessions. However, a persistent connection MAY be
closed after a few message exchanges. For example, a client may use
a persistent connection for the initial SETUP and PLAY message
exchanges in a session and then close the connection. Later, when
the client wishes to send a new request, such as a PAUSE for the
session, a new connection would be opened. This connection may be
either transient or persistent.
So no, it is not required to be open while streaming data.
The short answer is yes you must keep the rtsp socket open.
If the stream is over TCP the RTP packet travels over the socket of the RTSP session. If the stream is over UDP the socket is used by the server to know if it should keep sending packet to the client because the UDP packet transmission does not have any feedback if the client is still alive.
Edited:
I think the answer marked correct is actually incorrect. In general, the cameras implement the RTSP protocol version 1 not version 2. In the 10 years that I have of experience in video surveillance systems I have found that several models of cameras stop sending RTP packets after closing the RTSP session socket .
I'm imlempenting a RTSP client over TCP to communicate with the live555MediaServer .
The problem is that the server replies with "bad request 400" to my SETUP request
Could any one help me please ?
this is my setup request
"SETUP rtsp://192.168.121.133:8554/test.mpg RTSP/1.0\r\nCSeq: 3\r\nTransport: RTP/AVP;unicast;client_port=9000-9001\r\n\r\n";
There are a couple of issues with your command:
Take a look at the URL your are using in SETUP command, it should be the same (for each media stream, audio and video) you received as a reply to your DESCRIBE command.
You are actually setting up RTP over UDP, not TCP. RTP/AVP defaults to UDP (RFC2326, 12.39). TCP SETUP command should look something like: "SETUP ... RTSP/1.0\r\n\CSeq:...\r\nTransport: RTP/AVP/TCP;interleaved=0-1\r\n\r\n". Command details are described in RFC2326, 12.39
I have been using UDP sockets to send and receive voice through RTP packetization. It is pretty straightforward. I just send my mic voice signals ( that are encoded ) over IP using User Datagram socket , and on the other end i receive the UDP-RTP packets and decode them to be able to play them on my speakers.
I have been searching on internet for a while to find a way to start up a session using UDP sockets. What i want to to is to a Handshake-like process between two ends of my conversation and after the requests were acknowledged the media layer ( which i described in first paragraph ) would fire and start sending voice.
I have not been able to find any tutorials on session request using UDP sockets but i suppose it shouldnt be impossible.( one user sends a request to build a session and if the other user confirms media layer starts)
Has anyone done something like this before? any info is welcome.
Firstly, UDP is a connectionless, unreliable protocol, you won't find anything like handshaking for negotiating connection i.e no session management. But, to transport RTP packets it's not a good idea to use tcp, it lacks realtime feature, so you have to stick with UDP. Now, to overcome the signaling problem you can use protocols like. SIP. It's standard signaling protocol used in VOIP. SIP initiates a connection before sending RTP packets. To properly use SIP and RTP you might have to take help of another protocol called SDP, which tells which port to use for transmitting RTP and other various info. You can get more info about these techniques here. Hope this will helps!
I have:
one pc with videolan installed (windows 7) 192.168.1.2,
one pc with linux ubuntu 11.4 installed 192.168.1.12,
I've try to send a video via UDP (in videolan) from windows 7 to in linux-pc
throught port 8081
in linux I've run netcat listening on port 8081 and redirect to file, (netcat -lu 8081 >file.avi)
(my goal is to redirect to a serial in embeded linux snapgear,
by the way now I need to rediret to a file)
but don't works and I can figure out how config all, netcat don't write every byte sent on 8081?
thanks
update:
my problem is that I dunno address of source, take a look at the following scenario:
linux pc send stream to a serial, and other pc send to that pc a stream.
linux pc is alway in listening and don't know the address of source / sources,
this is my problem I dunno how to send with VLC, I know how send vlc to vlc (and it works)
but I dunno how send to 192.168.1.12:8081
thanks again
Your setup will probably not work: AVI is not designed to be streamed as-is over an unreliable transport layer protocol.
When you use VLC, it probably uses an encapsulation format like an MPEG transport stream or RTP, which you would have to properly decode before saving the contents to a file.
Even if you really manage to just stream the raw AVI file via UDP, you will run into problems because of packet loss and reordering - AVI is simply not designed to withstand that kind of errors.
You should either switch to a reliable transport protocol like HTTP (and even then use something else than AVI - it's really not designed for streaming), or use some other protocol to encapsulate your media, like an MPEG transport stream or RTP.
Please check your IP-Adresses. Do they really have the same?
Does the netcat work for other protocols? You may test it with the dns-port and nslookup on windows.
I have a simple Rtsp Client...The client send Rtsp Commands to Rtsp Server and get RTP packets from server.
The problem is that after a time( about 3-4 minute) my 3rd party RTSP
Server drop connection with my RTSP Client.
I have not implemented RTCP...I take rtp packets from rtsp server but does not send any RTCP PACKET...
I make simple search and find that some guys use some RTSP commands[ like OPTIONS, SET PARAMETER-GET PARAMETER ] too keep alive Connections between RTSP Server and Client...
But in my case that does not work...
Here is my questions:
What is the best way to keep alive connection with RTSP server?
Do i have to implement RTCP [ send RTCP packets to server]? May the connection drop because i do not send RTCP packets to server?
What is the value of timeout you receive in SETUP response? Are you using this value for implementing keep alive functionality?
Session = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds
]
Generally RTSP is based on TCP and RTP is based on UDP. So ideally both the channels require keep alive functionality. If RTP session is closed that does not mean that RTSP connection should also be teardown whereas RTP channels must be closed on RTSP channel teardown.
1) What is the best way to keep alive connection with RTSP server? --> Send any RTSP request periodically (OPTIONS, SET_PARAMETER or GET_PARAMETER) before timeout value received in SETUP response.
2) Do i have to implement RTCP [ send RTCP packets to server]? May the connection drop because i do not send RTCP packets to server? --> RFC (RTSP or RTP) does not mandate requirement of RTCP to keep RTP channels alive.
Sending an OPTIONS request didn't work for me.
The only RTSP command that I could send to keep the connection alive was GET_PARAMETER
My timeout is 60s and I send a GET_PARAMETER request every 40s
Works like a charm!
(No, you do not have to RTCP packets to the server)