|
Roni-
The RS generates the RMS-I, and the semantics of the RMS-I
are well defined from the standpoint of the RS. The Max Burst BitRate is the
maximum rate at which the RS will send the burst. If the RS knows this value, it
should populate the field.
The document does not currently specify what the RR does
with the Max Burst Bitrate, because the RR could do a lot of different things
with it. It may manage the de-jitter buffer. It may manage a decode buffer. It
may manage a decrypt buffer. It may manage display buffer. It may display
progress bars. It may present different screens to the user based on the
anticipated duration of the stream acquisition process. Most of this is
payload/implementation specific, and we are trying to stay away from specifying
such behaviors.
So, in summary, we are trying to rigorously define the
semantics of each component of each packet that flows on the network as seen by
the sender of that message. We are currently not trying to define the
device-specific actions that a given device takes when receiving a message.
Having said that, it sounds like we should put some
guidance in the text regarding possible uses for the receiver. We do need to be
careful not to make to many assumptions about application-specific behaviors,
though.
bvs
From: Roni Even [mailto:ron.even.tlv at gmail.com] Sent: Thursday, March 12, 2009 12:17 PM To: Bill Ver Steeg (versteb); yekuiwang at huawei.com; Ali C. Begen (abegen); avt at ietf.org Cc: Dave Oran (oran) Subject: RE: [AVT] NewVersion: draft-versteeg-avt-rapid-synchronization-for-rtp-02 Hi, I
will have a separate email with my review comments. I
have one comment on this thread
Roni:
I think that if you have a parameter in a message its semantics should be
specified. If it is not then how would an RS know if to put a value in this
parameter or just have it as unspecified. |