Re: [MMUSIC] FW: I-D Action:draft-stiemerling-rtsp-announce-01.txt

["Ganesan Sam-W00184" <sam.ganesan at motorola.com>]

In line 


Sam

-----Original Message-----
From: Joe Pallas [mailto:joe.pallas at gmail.com] On Behalf Of Joe Pallas
Sent: Thursday, March 06, 2008 12:38 PM
To: Ganesan Sam-W00184
Cc: Martin Stiemerling; mmusic at ietf.org
Subject: Re: [MMUSIC] FW: I-D
Action:draft-stiemerling-rtsp-announce-01.txt


On Mar 6, 2008, at 8:16 AM, Ganesan Sam-W00184 wrote:

> One of the questions that come to mind is the following
>
> 1.  RTSP specifically in both 1.0 and 2.0 disavow the notion of a 
> persistent connection.

I don't know what leads you to that conclusion.  Certainly it can't be
the text in section 10.2 of rfc2326bis that says, "A persistent
connection MAY be used for all transactions between the server and
client, including messages for multiple RTSP sessions.  However a
persistent connection MAY also be closed after a few message exchanges."

Persistent connections are clearly allowed, and I think any reasonable
person would say they are preferred if asynchronous server messages like
ANNOUNCE (or whatever it might be called) are to be used.

[Sam]
Yes they are allowed, I never said not... But here is the text that led
me to make that statement

	There is no notion of an RTSP connection in the protocol.
Instead,
   an RTSP server maintains a session labeled by an identifier to
   associate groups of media streams and their states.  An RTSP session
   is not tied to a transport-level connection such as a TCP connection.
   During a session, a client may open and close multiple reliable
   transport connections to the server to issue RTSP requests for that
   session.

> In one particular implementation where we tried not to have persistent

> connections, we actually ended up having a RTSP listener on the client

> for a call back by the server for asynch notifications

Just when you thought the NAT problem couldn't get any worse ....  I
would strongly oppose an approach that requires the server to be able to
make a TCP connection to the client.  The difficulties in getting that
to work through a firewall are overwhelming.

[Sam]
The reason I put it out there is because of the NAT problem.  In the
implementation I was looking at it was a closed network.  Yes I am aware
of the issue and I think it needs to be addressed...



joe

_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic