[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt
Hello Magnus,
[I address the signalling in this mail, and the timestamp block in a
subsequent mail.]
Getting a handle on the signalling for RTP XR reports is a major
priority. Thank you for taking the initiative to think through how it
might be done.
I wonder, though, if it would be alright if we were to submit this as a
subsequent draft. The concern is that introducing a significant change
at this point would make it difficult to proceed to working group last
call at San Francisco.
If not having signalling means we should not propose a standard then of
course we should wait. But to my mind the extended reports are useful
in themselves, and a proposed standard will allow important work to go
forward.
Part of this work will entail applications that deploy these reports.
With the experience gained, we may be in a better position to say
exactly how signalling should be done than we are now.
Best regards,
Timur
-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se]
Sent: Thursday, February 20, 2003 11:17 AM
To: Timur Friedman
Cc: avt@ietf.org
Subject: Re: [AVT] draft-ietf-avt-rtcp-report-extns-02.txt
Hi Timur,
I have in the last few weeks come to some insight on where I desire to
use some of the reporting blocks. Therefore I have two general comments
on what I would in fact like to add to the XR format:
1. I would like to add SDP signaling to the draft. In the use case of
streaming when only the server sends media to the client there is no
need for the server to send XR report blocks of other types then
responses to RTT measurements. However the server may very much desire
to receive the XR formats. However some other servers may not support
the XR format and then it would be waste of bandwidth. Therefore I see a
need for allowing the server to ask the client to send XR reports and
which formats it is interested in.
It also seem to be interesting to have the recipient ask for what
thinning factor it would like to see. Also the reporting overlap between
each packet, i.e. should each packet report on the new data from last
report and also how many already reported packets. All this is of course
only recommendations to the send of the XR packet. They may need to
reevaluate the request based on bandwidth consumption etc.
This is my motivation therefore I propose the following SDP parameter
chapter to be included in the draft:
----------------------------------
x SDP Signaling for the XR Format
To allow the recipient of XR format to specify what format it would
like to receive the following media level SDP attribute is defined. If
included in a SDP media block the recipient of the SDP is RECOMMENDED to
send RTCP XR reports containing the report blocks indicated in the
attribute. To allow the recipient to also direct the sender of XR
reports on what configuration it desires on each block some parameters
are also possible to define for each report block type. These are also
only recommendations to the sender and MAY be ignored due to other
considerations. Such other considerations is for example, complexity of
gathering the information, and the bandwidth usage imposed by the
reporting.
The SDP attribute is defined as following in ABNF of RFC 2234
XR-attriute = "a" "=" "rtcp-xr" ":" xr-format *(";" xr-format) CRLF
xr-format = loss-rle-def
/ dupp-rle-def
/ timestamp-def
/ stat-sum-def
/ rcv-time-RTT-def
/ DLRR-def
/ VOIP-metrics-def
/ extension-type
loss-rle-def = "loss-rle" "=" overlap "/" thinning-factor
dupp-rle-def = "dupp-rle" "=" overlap "/" thinning-factor
timestamp-def = "rcv-time" "=" overlap "/" thinning-factor
stat-sum-def = "stat-sum" "=" loss-flag "/" dupp-flag "/" jitt-flag "/"
TTL-flag
loss-flag = boolean ; Include loss block
dupp-flag = boolean ; Include duplicate block
jitt-flag = boolean ; Include jitter block
ttl-flag = boolean ; Include TTL block
boolean = "0" / "1" ; False or True
rcv-time-RTT-def = "rcv-rtt" "=" boolean
DLRR-def = "dlrr" "=" boolean
VOIP-metrics-def = "voip" "=" "1"
extension-type = token "=" Value *("/" Value)
Value = token / quoted-stirng
overlap = 1*DIGIT ;
thinning-factor = 1*2DIGIT ; 0-15 is valid values
The "overlap" factor tells the sender of reports how many reporting
intervals the statistics should cover. A overlap factor of 0 means only
information gathered since the last report using this format. An overlap
factor of 1 would mean that the reporter should send information
gathered both since the last sent report and the previous sent report
packet.
The thinning factor is the value the reporter should use in its report.
It is defined for each of the report blocks that has this value and
valid values are 0-15.
The "stat-sum" parameter contains boolean flags (0 or 1) for each of the
four parts that can be included in this packet. The "stat-sum" parameter
SHOULD NOT be included unless at least one of the block flags are true,
i.e. signaling inclusion of some block.
The "rcv-rtt" parameter tells the receiver of this SDP if it can use the
block or not within the session. By including this parameter with a true
value the source of the SDP indicates that it will respond using the
DLRR report block and that it is meaningful to send Receiver Timestamp
Report Block. This parameter is useful for servers or multicast senders
to indicate its support for allowing the receiver to measure the RTT. It
is always the receivers choice to send Receiver Timestamp Report blocks.
The "dlrr" parameter indicates by its value of true or false if the
reporter SHOULD answer Receiver Timestamp report blocks it receives
using the DLRR report block. This allows a multicast session sender to
recommend the receiver of the session to not waste RTCP bandwidth on RTT
measurements.
The presence of the "voip" parameter indicates that the reporter is
RECOMMENDED to include the report block in the RTCP XR format. It has a
hard coded value to simplify parsing as all parameters have the
structure <parameter name> = <values>
This format is extensible as new report blocks are included. Recipients
of the SDP attribute SHOULD ignore any unknown parameters by skipping to
past the next ";" or if non present to the end of line.
-----------------------------------
A IANA repository needs to be established for this SDP attribute to
enable future extensions. The same rules that applies to registering XR
report blocks apply to registering new attribute parameters.
...
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt