Subject: [MMUSIC] RTSP questions/comments

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 12 Dec 2008 14:47:21 +0100

Hi

I have a few questions/comments to 2326bis.

Section 19.3.1 (end)
===============================
   .....If
   no such transport connection exist at the time when the server desire
   to send the request, it silently fails.
===============================
What does this mean in practice ?, there must be a timeout mechanism of some sorts involved here, I believe that some kind of a description would be good. 

Section 22.8.1 
===============================
   Notify-Reason values are the way to indicate why a notification was
   sent.  It may also imply that certain headers shall or should be
   present required for the client to act upon the information the
   notification carries.  New notification behaviors do need to be
   described to result in interoperable usage, thus specification are
   required.
===============================
Confusing, I would suggest a rewrite like 
===============================
   Notify-Reason values used to indicate why a notification was
   sent.  They may also imply that certain headers are required
   for the client to act properly upon the information the 
   notification carries.  New notification behaviors need to be
   described to result in interoperable usage, thus a specification of 
   each new value is required.
===============================

Section C.1.6.3.
===============================
   This can be determined by comparing on short to medium term (some
   seconds) the used bit-rate and adapt it so that the RTP sender sends
   at a bit-rate comparable to what a TCP sender would achieve on
   average over the same path.
===============================
I've seen this formulation elsewhere, for instance in 3984bis. Is the intent that one run some kind of TFRC emulation in the sender based on received RTCP-RR ?.

Regards
Ingemar 
******************************************* 
Ingemar Johansson 
Senior Research Engineer, IETF "nethead" 
EAB/TVP - Multimedia Technologies 
Ericsson Research Ericsson AB 
Box 920 S-971 28 Luleå, Sweden 
Tel: +46 (0)10 7143042 
ECN: 852-43042 
ECC: 852-19042
Mobile: +46 (0)730 783289 
Visit http://labs.ericsson.com !
******************************************* 
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 16 Dec 2008 15:05:02 +0100

> I have a few questions/comments to 2326bis.

I would interpret that such a server->client request would immediately
be discarded if no connection to the client exist. There would be no
timeout simply a discard action to avoid a lot of request building up.

I think a clarification of this actually belongs in the connection
section (Section 10). I have attempted some clarification there:

RTSP allows a server to send requests to a client. However, this can be
supported only if a client establishes a persistent connection with the
server. In cases where a persistent connection does not exist between a
server and its client, due to the lack of a signalling channel the
server may be forced to silently discard RTSP messages, and may even
drop an RTSP session without notifying the client. An example of such a
case is when the server desires to send a REDIRECT request for an RTSP
session to the client but is not able to do so because it cannot reach
the client. A server that attempt to send a request to a client that has
no connection currently to the server SHOULD discard the request
directly, it MAY queue it for later delivery. However, if the server
queue the request it should when adding additional requests to the queue
ensure to remove older requests that are now redundant.

> Section 22.8.1 

Makes a lot of sense. Text has been included.

> I've seen this formulation elsewhere, for instance in 3984bis. Is the intent that one run some kind of TFRC emulation in the sender based on received RTCP-RR ?.

This formulation is due to the lack of any specification that is
guaranteed to work. Instead a general requirement on the behavior is
provided. It doesn't require any specific solution only that it behaves
in the right ball park. TFRC may be one solution that can fulfill this,
but there exist others.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic