[ortc] RTX apt vs PayloadType within RTCRtpRtxParameters

robin-raymond has just created a new issue for 
https://github.com/openpeer/ortc:

== RTX apt vs PayloadType within RTCRtpRtxParameters ==
$related https://github.com/w3c/webrtc-pc/issues/548

For RTX to work there needs to be a mapping between the RTX payload 
type and the original payload being used with RTX. E.g. the mapping of
 the RTX payload type to the original VP8 codec payload type. In SDP, 
that is via `apt`. In ORTC, that mapping is defined within the 
`RTCRtpRtxParameters.payloadType`.

While in theory this makes ORTC more flexible, it actually can cause 
some interesting and problematic routing issues. Specifically, it's 
possible to use a `payloadType` within `RTCRtpRtxParameters` of a 
value not defined within the codec list at all to mean the "RTX" 
`payloadType` for this encoding. This means that one encoding could 
define `98` to be the RTX for VP8 with SSRC `1000`. On another 
encoding RTX for VP9 could be defined as `98` as well with SSRC 
`2000`. This mean that the RTX payload type could be dependent on the 
SSRC in use within the same list of encodings.

I do not see a strong use case to support this flexibility and it 
creates complex routing which requires that the RTX payload types are 
only understood within the context of a specific SSRC. If we truly 
want per SSRC specific flexibility I would suggest a developer use 
multiple receivers be used or alternatively that we make all codecs 
defined within the context of a specific encoding rather than having a
 codec list at all (which is a rather significant change of course at 
this time). As I don't see anyone really clamouring to require that 
level of flexibility then I suggest the interpretation of payload 
types be specific exclusively in meaning to the codec list and not be 
SSRC dependent at all.


Please view or discuss this issue at 
https://github.com/openpeer/ortc/issues/436 using your GitHub account

Received on Thursday, 17 March 2016 20:39:55 UTC