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)
Related
I want to be able to receive SYN packets from a client, but not send back a SYNACK response. I have tried a few things. If you use raw sockets, it is possible to receive the full packet but linux kernel seems to automatically send back a FINACK packet. I found out that this was because I did not have a service actually listening to the port I was monitoring. My next step was to bind a socket to the port I was interested in, and use the listen() syscall to listen to that port, along with the raw socket. This approach results in the kernel automatically sending back a SYNACK rather than a FINACK. Is there anyway to receive a raw packet, and not send back an automated response? It seems that raw sockets can only snoop on packets, rather than actually handle them. I have also tried using a UDP server socket to listen to the target port, but I am still sending back an automatic FINACK.
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 .
Spring-Integration , TCP Serve will push Packet to my Application and once packet received will send Ack to server. At last send final response once after processing done. I have to keep connection open until packet processed. I am new
Please help.
Sounds like you need to use a TcpInboundGateway with the TcpNetClientConnectionFactory: https://docs.spring.io/spring-integration/docs/5.0.7.RELEASE/reference/html/ip.html#tcp-connection-factories
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.
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!