[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] FW: I-D Action:draft-stiemerling-rtsp-announce-01.txt
I was thinking about the ANNOUNCE style notification and a second case where the server may have to notify the client of a change is stream format change in terms of say frame rate. I know it is a hypothetical but it might be worth thinking about as a second case as well
Sam
-----Original Message-----
From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On Behalf Of Magnus Westerlund
Sent: Friday, March 07, 2008 10:34 AM
To: Rémi Denis-Courmont
Cc: Martin Stiemerling; mmusic at ietf.org
Subject: 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
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic