Re: Mapping RTX in SDP to ORTC RtpParameters

2016-03-04 6:45 GMT+01:00 Philipp Hancke <>:
> the following change landed ~2 weeks ago in Chrome (omitting non-relevant
> lines):
> a=rtpmap:100 VP8/90000
> a=rtpmap:101 VP9/90000
> a=rtpmap:116 red/90000
> a=rtpmap:117 ulpfec/90000
> a=rtpmap:96 rtx/90000
> a=fmtp:96 apt=100
> a=rtpmap:97 rtx/90000
> a=fmtp:97 apt=101
> a=rtpmap:98 rtx/90000
> a=fmtp:98 apt=116
> a=ssrc-group:FID 3394089718 2597890963
> a=ssrc:3394089718 cname:KW7QnMvNSxEzPmpQ
> a=ssrc:2597890963 cname:KW7QnMvNSxEzPmpQ
> no additional ssrc is added. And I do not think it is necessary...


>> 2) If 1) is correct, how to map it in ORTC? According to the spec:
>>    9.12.1 Dictionary RTCRtpRtxParameters Members
>>    payloadType
>>      The payload type to use for retransmission. If unset,
>>      RTCRtpCodecParameters.payloadType for the "rtx" codec is used.
>>    ssrc
>>      The SSRC to use for retransmission, as specified in [RFC4588].
>> But how to specify the relationship between rtx:96 and VP8:100, and
>> rtx:97 and VP9:101? Should it be done by setting 100 and 101 in the
>> `codecPayloadType` of each RtpEncondingParameters object?
> the relationship is defined by the parameters in RTCRtpCodecParameters which
> would be {apt: 100} for the first rtx codec.

I think that is totally wrong:

- 'apt' is just a SDP fmtp parameter, it does not even appear in ORTC,
and I hope we don't must rely on a generic parameter/value container
for associating a RTX and its related media codec.

- We have the encoding.codecPayloadType and encoding.rtx for that (as
Bernard said):

>       parameters.codecs[3].name = "vp8"
>       parameters.codecs[3].payloadType = 100;
>       parameters.encodings[0].ssrc = 1762798695;
>       parameters.encodings[0].codecPayloadType = 100;
>       parameters.encodings[0].rtx.ssrc = 3360043549;
>       parameters.encodings[0].rtx.payloadType = 96;

>> 3) How to know which SSRC will be used for VP8:100+VP9:101, rtx:96,
>> and rtx:97 streams? The line ssrc-group just states that those tree
>> SSRC values have a relationship, but RFC4588 does not define how each
>> SSRC in a group is associated to the sending codecs.
> the ssrc will be the same, the codec is determined by the PT. You need both
> to demultiplex. Makes sense?

Fine with me, but this leads to

Thanks a lot.

P.S. Anticipating future threads/issues that I'll report:

- There shouldn't be 'rtx' codec. Instead `rtx` stuff should be
defined per `encoding`.

- codec should not have `clockRate` since it is related to the whole

- codec.payloadType should be unique within a RtpParameters.

- encoding.codecPalyloadType should be *mandatory*. Each media codec
should have its associated encoding (when there are multiple ways of
expressing the same something is wrong in the spec and will lead to
interoperability problems).

Iñaki Baz Castillo

Received on Friday, 4 March 2016 11:11:43 UTC