|
Tom, I think this question should go to mmusic. What you are trying
to do here is to define semantics for the content of a RTCP flow pointing to
different devices. The m-line or the RTCP line in SDP does not address what is
the content of the stream that will go in the RTP session. RFC 4796
addresses the media content issue but you are looking for something similar to
the RTCP attribute. This may require a new parameter to the rtcp attribute. You will also need to look at backward interoperability where
the receiver will not understand this semantics and may change the RTCP message
to the wrong address. The example for the content attribute was to specify to video
m-lines one with screen capture as a video stream and the other from a camera.
SDP does not define the behavior of the receiver if it receives two m-lines of
the same media type and can only support one. It is not clear which one he will
chose (first or second). The work on capability negotiation tries to address
this issue. Roni Even From:
avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of VAN
CAENEGEM Tom Hi, I have two
questions/comments mostly regarding the RTCP-SSM draft (http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18). The background of
my questions is the use case of "broadcast channels" in an IPTV
context, where the channels are distributed over IP multicast (SSM). In this
context, the concept of feedback target(s) is obviously very useful, and
actually necessary given today's restrictions with multicast in upstream in the
"WAN". For the IPTV
use case, it also makes sense to have multiple feedback targets, each
responsible for a subset of RTP receivers, because of the large number of RTP
receivers involved (100.000s is possible). The way to signal this by means of
SDP is that each local subset of RTP receivers sees a different IP address in
the "a=rtcp:
"portnumber" IN IP4 "IP address" line.
So, multiple "localised" FT is covered by the draft IMO. However, in
that case, the maximum bandwidth that can be used for RTCP reporting by RTP receivers
only needs to be determined by the size of the local group of RTP receivers
(sending RTCP to the same localised Feedback Target), especially in the summary
FB model. But in my interpretation of the architecture, the actual RTCP
bandwith limit information can only be retrieved by the RTP receivers from the
information sent by the distribution source in the ssm session. Either by
refected RTCP reports from RTP receivers (not a feasible solution for the given
use case) or from a RSI message -in the summary FB model- indicating the
session size or explicitly the RTCP reporting bandwidth limit. The fact is that
this information is sent to ALL RTP receivers, which may be reporting to
different Feedback targets where each Feedback target is collecting RTCP messages
from a different number of RTP receivers, and hence may have different
"requirements" for total RTCP reporting bandwidth limit. My
question is whether local Feedback targets have been considered with respect to
this issue? My second
question again has to do with multiple feedback targets for the same use case. In the IPTV
use case for rtcpssm, Feedback Targets can also be used as retransmission
sources (RFC 4588) and in http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03, the feedback target
architecture is used to allow fast acquisition of SSM RTP sessions. The draft
proposes that a "burst source" is co-located with the FT which
transmits unicast data (starting with a random access point of the video
channel) from a cache that holds the most recent data distributed over the RTP
SSM. It does transmit the RTP packets at an accelerated speed, allowing the RTP
receiver to join the SSM after some time. The idea I
would like to bring forward is to allow separate Feedback Targets for the
same RTP receiver (population): one Feedback target acts as RTP retransmission
server (see http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03) and collects RTCP
FB messages, while the other Feedback Target is solely "responsible"
for the non RTCP-FB messages, such as RTCP XR messages. I realise this idea is
not necessarily linked with the rtcp-ssm draft, but IMO only for a
massive scale application that makes use of RTP and leverages rtcp ssm such a
separation is justified. The possibility for separation of the monitoring service
–associated
with a server function basically responsible for collecting RTCP receiver
reports for the purpose of monitoring- and the retransmission service requiring
a server function that is responsible for processing and responding to RTCP FB
messages, is driven from the point of view of server function optimisation
(different requirements on the server platform). In terms of
signaling two Feedback Targets, we could make use of the following lines:
a=rtcp:40001
IN IP4 192.0.2.1 (This is for retransmission) However,
that is probably quite ambiguous..? Comments
appreciated on this idea. Kind
regards,
|