ORTC and FEC/RTX/RED

On Oct 22, 2014, at 12:34 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com<mailto:sergio.garcia.murillo@gmail.com>> wrote:

Hi,

I disagree, It is not possible just by looking at the SDP to know which ssrc is from the media and which is from rtx. While for WebRTC-endpoints it may be irrelevant because, as you say, you can wait for the RTP data to check the payload type and match the ssrc, we have seen that it is a must have for interoperability with ORTC.

Best regards
Sergio

[BA] Currently FEC/RED/RTX capabilities are in part discovered and configured as codecs, which can include a payload type. In addition the SSRCs can be configured. As Inaki discovered, there is no "apt" parameter defined in RED, but that could be added. So putting aside the issue of whether the present design is awkward, is there a loss of functionality from WebRTC 1.0?

My take so far is that as long as the matching rules guide the RTX/FEC/RED streams to the same RtpReceiver as the media streams they are associated with, we are OK. In the case of multiple sources this could be a bit tricky if the receivers are sharing payload types, but that is where the SSRC configuration comes in.

On Oct 22, 2014, at 12:16 PM, Suhas Nandakumar <suhasietf@gmail.com<mailto:suhasietf@gmail.com>> wrote:

Just thinking loud
 As long as there is enough information to unabigously map the incoming streams to the SDP, i dont see we need any more information to be added.

I feel the combination of SSRC and Payload Type in the RTP packet is good enough to find the mapping to the appropriate media line (if the PTs are not repeated) when needed.

So in the initial examples above, ssrc-group communicated in SDP along with semantics (FEC,FID) when applied to incoming SSRCs and the associated payload type has all the needed info for the receiver to demux at the rtp level as well as map at the SDP level. Thus i dont see a need for specifying PT association explicitly in SDP for the ssrc-groups.

Cheers
Suhas

On Wed, Oct 22, 2014 at 12:01 PM, Bernard Aboba <bernard.aboba@gmail.com<mailto:bernard.aboba@gmail.com>> wrote:
SDP specifies payload types for RED/ULPFEC/RTX so as to allow differentiation within an ssrc-group. So while an fmtp: attribute could be used to denote a media stream on an a:ssrc line, it is not necessary.

RFC 5576 Example 3 gives an example with two cameras in which there are two ssrc-group lines (one for each camera), with payload type used to differentiate between H.264 and RTX in each ssrc-group:



   m=video 49174 RTP/AVPF 96 98

 a=rtpmap:96 H.264/90000

 a=rtpmap:98 rtx/90000

 a=fmtp:98 apt=96;rtx-time=3000

 a=ssrc-group:FID 11111 22222

 a=ssrc:11111 cname:user3@example.com<http://example.com>

 a=ssrc:22222 cname:user3@example.com<http://example.com>

 a=ssrc-group:FID 33333 44444

 a=ssrc:33333 cname:user3@example.com<http://example.com>

 a=ssrc:44444 cname:user3@example.com<http://example.com>






I believe that RFC 5576 includes the two groups to make clear that there are two sources so that the Answerer might choose to reject the m-line if it cannot handle that. From RFC 5176 Section 8:





When used with the SDP Offer/Answer Model [RFC3264<http://tools.ietf.org/html/rfc3264>], SDP source-specific attributes describe only the sources that each party is
   willing to send (whether it is sending RTP data or RTCP report
   blocks).  No mechanism is provided by which an answer can accept or
   reject individual sources within a media stream; if the set of
   sources in a media stream is unacceptable, the answerer's only option
   is to reject the media stream or the entire multimedia session.





Note that in the example in RFC 4588 Section 8.8 where there is only one source, there are no ssrc-group lines at all:





 v=0

 o=mascha 2980675221 2980675778 IN IP4 host.example.net<http://host.example.net>

 c=IN IP4 192.0.2.0

 m=video 49170 RTP/AVPF 96 97

 a=rtpmap:96 MP4V-ES/90000

 a=rtcp-fb:96 nack

 a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F

 a=rtpmap:97 rtx/90000

 a=fmtp:97 apt=96;rtx-time=3000

The situation would be the same for FEC groups created via ssrc-group:FEC. From
https://tools.ietf.org/html/draft-lennox-payload-ulp-ssrc-mux  :


      The FEC and the payload MAY also be multiplexed by SSRC into one
      single RTP session, with separate SSRC values, if the association
      between FEC and payload streams are communicated to all members of
      the session.  If SDP is used, this association MAY be communicated
      through the FEC ssrc-group semantic [RFC5576<https://tools.ietf.org/html/rfc5576>]; other mechanisms
      are also possible.  Receivers MUST NOT attempt to interpret FEC
      streams for which they do not have information to associate them
      with the corresponding payload streams.