Re: [MMUSIC] RTSP questions in regards to the control channel socket

[Magnus Westerlund <[e-mail]>]

On 2014-03-15 18:41, Craig Matsuura wrote:
> Hi Magnus,
> 
> Thanks for your response, to be clear when I was referring to a Control 
> Socket I mean the connection that sends commands such as the DESCRIBE, 
> OPTIONS, SETUP.  So to restate, it should not matter if a connection for 
> the transports comes or goes to server.  For example if a server flow to 
> a client is:
> 
> C->S - Send DESCRIBE Command, C gets 200 response from S.
> Close connection and start new connection
> C->S - Send OPTIONS command, C gets 200 response from S.
> Close connection and start new connection
> C->S - Send SETUP command, C gets ??? response from S.
> 
> So at the SETUP the response should be 200? or fail (400)?  I'm trying 
> to clear up an issue I have with a vendors RTSP Server implementation 
> and would like to know if the sequence above should work to a RTSP 
> Server.  Based on the Section 1.1 and 1.7 seems the above should work.  
> The only issue would be after the SETUP the session id needs to 
> accompany commands that follow?

Yes, according to my interpretation of RFC 2326 that should be
completely valid and the SETUP request result in a 200 OK with a session
ID that is later used to reference that session.

/Magnus

> 
> Thanks,
> Craig
> 
> 
> On 03/14/2014 04:17 AM, Magnus Westerlund wrote:
>> On 2014-03-14 00:22, Craig Matsuura wrote:
>>> Hi this is my first time posting here.  I have a basic question about
>>> how a RTSP server should handled a connect and disconnect for what I am
>>> calling the control channel (connection or transport). The control
>>> channel (please correct me) is what sends the DESCRIBE, SETUP, OPTIONS,
>>> PLAY commands to the RTSP SERVER.
>>>
>>> Should a server treat the first DESCRIBE connection as its session. So
>>> in the case where a socket connects to a RTSP server and sends a
>>> DESCRIBE, is disconnected either by the client or some failure on the
>>> server should the following SETUP succeed?
>> No, DESCRIBE is a state less operation. If one needs a linkage between
>> the Describe response body and the setup, then one should use etags and
>> conditional requests to ensure that one is establishing the session with
>> a relevant session description.
>>
>>> Also if using a RTSP Proxy and in the same scenario, but after the
>>> DESCRIBE and closing of the socket a new socket is open to send an
>>> OPTIONS (for keepalive) should the following SETUP succeed?
>> Yes the SETUP should succeed if otherwise valid.
>>
>>>   From what I understood from the RFC2326 Section 1.7 RTSP State, it
>>> should not matter how many connections are used to control the RTSP Stream.
>>>
>>> 1. Control Socket is not prevent a client from connecting and
>>> disconnecting to send Transport commands.
>> I am uncertain what you mean with the Control socket, if you means the
>> Socket the server listens to incoming TCP connection establishments and
>> their data, it needs to be accepting those comming and going.
>>
>>> 2. The keep-alive for a session should not start until a SETUP command,
>>> which can optional report the timeout for the session.
>> Exact, the keep-alive is associated with the RTSP session, not the
>> signalling connection used to send RTSP requests and response between
>> the server and client.
>>
>> You might find RTSP 2.0's text on this being clearer:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------
>> Services, Media and Network features, Ericsson Research EAB/TXM
>> ----------------------------------------------------------------------
>> Ericsson AB                 | Phone  [phone]
>> Färögatan 6                 | Mobile [phone]
>> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>> ----------------------------------------------------------------------
>>
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------