[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] FW: I-D Action:draft-stiemerling-rtsp-announce-01.txt
Rémi Denis-Courmont skrev:
> Le Friday 07 March 2008 16:37:00 Joe Pallas, vous avez écrit :
>> One thing I think should be included is some discussion about how the
>> server associates a TCP connection with an RTSP session. Obviously,
>> the TCP connection that a SETUP request comes in on would be used for
>> that session while the connection is active. If that connection is
>> terminated before the session is torn down, and a client establishes
>> a new TCP connection before the session times out, the server needs
>> to recognize that the new connection is associated with that session.
>
> That's a pretty good point. Then again, perhaps clients that care about
> ANNOUNCE could simply be required to keep the session open, and servers that
> support ANNOUNCE must not timeout RTSP connections that have one or more
> session "associated" to them (yeah I know in theory there is currently no
> association).
>
> One innocent and clueless question is, why does RTSP allow non-permanent
> connections? One bad reason could be to save server resources - scaling many
> TCP connections is not such a big deal on server-grade operating systems
> nowadays, and many (most?) RTSP clients use persistent connections anyway.
> I suppose one good reason may be support for media handovers... ?
>
To be robust against faults is definitely part of the answer. It also
enables support for client movement, and hand-over of the control to
other parties.
But, in reality connections should really be persistent.
> When it comes to end-of-stream notification, we could perhaps use an in-band
> mechanism? not sure if RTCP BYE is valid there, but something similar could.
> Also for connection-oriented media, the server could simply reset the
> connection.
As discussed both RTCP BYE and reset of connections are not appropriate
as a client may directly after media have completed a media delivery
request a new media delivery. Thus having indicated that you not any
longer are using the SSRC (RTCP BYE) requires on to create a new
synchronization context, thus potentially reducing media quality.
>
>> This doesn't need to be complicated: the last connection that
>> received a request with the session-id should probably be the
>> connection associated with the session, and the client can achieve
>> this by sending a keep-alive style SET_PARAMETER. But saying so
>> explicitly might be a good idea.
>
> Is Session: valid for OPTIONS requests?
>
Yes, it may be included.
Cheers
Magnus Westerlund
IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic