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

Craig Matsuura <cmatsuura@vivint.com> Thu, 13 March 2014 23:22 UTC

Return-Path: <cmatsuura@vivint.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A9E1A0783 for <mmusic@ietfa.amsl.com>; Thu, 13 Mar 2014 16:22:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrHknJA2HQbO for <mmusic@ietfa.amsl.com>; Thu, 13 Mar 2014 16:22:26 -0700 (PDT)
Received: from inferno.apxalarm.com (inferno.apxalarm.com [65.181.58.40]) by ietfa.amsl.com (Postfix) with ESMTP id 608181A06EE for <mmusic@ietf.org>; Thu, 13 Mar 2014 16:22:26 -0700 (PDT)
Received: from MAILBOX.APEX.Local ([192.168.0.1]) by mail01.APEX.Local ([10.2.0.11]) with mapi; Thu, 13 Mar 2014 17:22:19 -0600
From: Craig Matsuura <cmatsuura@vivint.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Date: Thu, 13 Mar 2014 17:22:18 -0600
Thread-Topic: RTSP questions in regards to the control channel socket
Thread-Index: Ac8/ExPLGQBYTesrS7Wb7tzatid3Vw==
Message-ID: <53223DAA.4040107@vivint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/w3cxmXwWXSq7v0fkuNZWmNZnK-c
Subject: [MMUSIC] RTSP questions in regards to the control channel socket
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Mar 2014 23:28:54 -0000

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?

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?

 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.
2. The keep-alive for a session should not start until a SETUP command, 
which can optional report the timeout for the session.

Thanks,
Craig