RE: payload agnostic rtcp feedback

Here is what RFC 4585 Section 4.2 says: 

   A new payload format-specific SDP attribute is defined to indicate
   the capability of using RTCP feedback as specified in this document:
   "a=rtcp-fb".  The "rtcp-fb" attribute MUST only be used as an SDP
   media attribute and MUST NOT be provided at the session level.  The
   "rtcp-fb" attribute MUST only be used in media sessions for which the
   "AVPF" is specified.

   The "rtcp-fb" attribute SHOULD be used to indicate which RTCP FB
   messages MAY be used in this media session for the indicated payload
   type.  A wildcard payload type ("*") MAY be used to indicate that the
   RTCP feedback attribute applies to all payload types.  If several
   types of feedback are supported and/or the same feedback shall be
   specified for a subset of the payload types, several "a=rtcp-fb"
   lines MUST be used.

The implication here is that a=rtcp-fb lines can be provided for each payload type.
The RTCRtpCodecCapability dictionary provides the information on which codecs
support what feedback mechanisms, along with a preferredPayloadType that enables
the appropriate a=rtcp-fb lines to be constructed in an offer: 

dictionary RTCRtpCodecCapability {
    DOMString                 name;
    DOMString                 kind;
    unsigned long             clockRate;
    payloadtype               preferredPayloadType;
    unsigned long             numChannels;
    sequence<RTCRtcpFeedback> rtcpFeedback;
    Dictionary                parameters;
    Dictionary                options;
    unsigned short            maxTemporalLayers = 0;
    unsigned short            maxSpatialLayers = 0;
    boolean                   svcMultiStreamSupport;
};

Similarly, once an answer is received, the RTCRtpCodecParameters dictionary can be used to set the feedback mechanisms to be used for each codec: 

dictionary RTCRtpCodecParameters {
    DOMString                 name;
    payloadtype               payloadType;
    unsigned long             clockRate;
    unsigned long             numChannels;
    sequence<RTCRtcpFeedback> rtcpFeedback;
    Dictionary                parameters;
};

An example offer based on draft-burman-mmusic-sdp-simulcast Section 6.3.2 is shown below. 
In this example, it is assumed that PLI and NACK are supported by the H.264 codec (used as a base layer
in the example), whereas H.264/SVC supports PLI and NACK, with only NACK being advertised when
H.264/SVC is used as an extension to an H.264 base layer.    Also in the example below it is assumed
that the VP8 codec supports NACK, PLI, RPSI and SLI.  

   v=0
   o=fred 238947129 823479223 IN IP4 192.0.2.125
   s=Offer from Simulcast Enabled Multi-Source Client
   t=0 0
   c=IN IP4 192.0.2.125
   a=group:BUNDLE foo bar zen
   m=audio 49200 RTP/SAVPF 99
   a=mid:foo
   a=rtpmap:99 G722/8000
   m=video 49600 RTP/SAVPF 100 101 102 103
   a=mid:bar
   a=rtpmap:100 H264-SVC/90000
   a=rtpmap:101 H264/90000
   a=rtpmap:102 H264/90000
   a=rtpmap:103 VP8/90000
   a=fmtp:100 profile-level-id=42400d; max-fs=3600; max-mbps=108000; mst-mode=NI-TC
   a=fmtp:101 profile-level-id=42c00d; max-fs=3600; max-mbps=54000
   a=fmtp:102 profile-level-id=42c00d; max-fs=900; max-mbps=27000
   a=fmtp:103 max-fs=900; max-fr=30
   a=rtcp-fb:100 nack
   a=rtcp-fb:101 nack pli
   a=rtcp-fb:102 nack pli
   a=rtcp-fb:103 nack pli rpsi sli
   a=imageattr:100 send [x=1280,y=720] recv [x=1280,y=720]
   a=imageattr:101 send [x=1280,y=720] recv [x=1280,y=720]
   a=imageattr:102 send [x=640,y=360] recv [x=640,y=360]
   a=imageattr:103 send [x=640,y=360] recv [x=640,y=360]
   a=depend:100 lay bar:101
   a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
   a=simulcast sendrecv 100;101 send 103,102
   m=video 49602 RTP/SAVPF 96 103 97 104 105 106
   a=mid:zen
   a=rtpmap:96 VP8/90000
   a=fmtp:96 max-fs=3600; max-fr=30
   a=rtcp-fb:96 nack pli rpsi sli





________________________________________
From: Jiannan Zheng [jzheng@exchange.microsoft.com]
Sent: Wednesday, November 19, 2014 12:07 PM
To: public-ortc@w3.org
Subject: payload agnostic rtcp feedback

Hi,

I have a question about how to enable the app built on top of ORTC to be able to generate thing like:
“a = rtcp-fb:* nack pli”

Now it seems the feedback capability is attached to each codec and there is not easy way to specify a global one.

Thanks,

-Jiannan

Received on Wednesday, 19 November 2014 22:16:41 UTC