Re: RTX support (RFC 4588)

On Tue, Oct 21, 2014 at 1:15 AM, Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

>  Hi Peter,
>
> Re. Session-Multiplexing support on ORTC. I am perfeclty fine, and I think
> that makes sense, but on RTP-USAGE draft it says :
>
>    Receivers are REQUIRED to implement support for RTP retransmission
>    packets [RFC4588 <https://tools.ietf.org/html/rfc4588>].
>
>
> So either we ask webrtc to narrow that requirement to support
> ssrc-mutliplexing only, or we should explicitly state in the ORTC draft
> that we doesn't support session multiplexing.
>
>
​Does that phrase mean there must be ​a way to send RTX, or there must be
all possible ways to send RTX?  It seems a bit ambiguous to me.  By the
way, I'm pretty sure none of the current WebRTC implementations support
session-multiplexing RTX right now (I'm sure Chrome doesn't support it).



> Re. setting the ssrc in the RtxParameters, thanks for the clarification, I
> missed it completely. For the sending side it solves the issue, but I am
> not sure it will work in there receiver side when talking to an WebRTC
> endpoint.
>
> In the SDP offer of an webrtc endpoint both ssrcs of the media and rtx
> streams are informed within an ssrc-group attribute, but it is not possible
> to tell in advance which of both ssrcs is the rtx one, as an example of
> current chrome offer (removing unrelated sdp attributes).
>
> v=0
> o=- 7628761646234407083 2 IN IP4 127.0.0.1
> s=-
> t=0 0
> a=group:BUNDLE audio video
> a=msid-semantic: WMS DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
> m=audio 62164 RTP/SAVPF 111 103 104 0 8 106 105 13 126
> a=rtpmap:111 opus/48000/2
> a=fmtp:111 minptime=10
> a=ssrc:3415393492 cname:erS7E/KHLYKTejNs
> a=ssrc:3415393492 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
> 2d6a25e5-0e71-4da4-9f92-457f265b42ad
> a=ssrc:3415393492 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
> a=ssrc:3415393492 label:2d6a25e5-0e71-4da4-9f92-457f265b42ad
> m=video 62164 RTP/SAVPF 100 116 117 96
> a=mid:video
> a=rtpmap:100 VP8/90000
> a=rtpmap:116 red/90000
> a=rtpmap:117 ulpfec/90000
> a=rtpmap:96 rtx/90000
> a=fmtp:96 apt=100
> a=ssrc-group:FID 345259865 2693756249
> a=ssrc:345259865 cname:erS7E/KHLYKTejNs
> a=ssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
> c0134f05-e7c2-4afd-a979-4e224de5eb91
> a=ssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
> a=ssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
> a=ssrc:2693756249 cname:erS7E/KHLYKTejNs
> a=ssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
> c0134f05-e7c2-4afd-a979-4e224de5eb91
> a=ssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
> a=ssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
>



>
> So, at least that I am aware of, it is not possible to now in advance
> which of 345259865  or 2693756249 corresponds to the rtx stream. In this
> case, the ortc implementation may still behave correctly as only one of the
> streams in the bundle has the rtx codec, but not sure how would it be able
> to choose what stream an rtx packets belong, if for example the audio
> stream has also a rtx codec, or there is more than one video stream with
> rtx in the rtp session.
>

​​In Chrome, that SDP is interpreted to mean that the RTX ssrc is
​2693756249, which makes it unambiguous and possible to know in advance.
ORTC follows the same model: it's unambiguous and possible to know in
advance.


>
> Best regardrs
> Sergio
>
>
>
> On 20/10/2014 19:21, Peter Thatcher wrote:
>
>  You can use ssrc-multiplexing by setting the SSRC of the RtxParameters
> in RtpEncodingParameters.  RtcpParameters is not the right place for this.
>
>  Session-multiplexing is not supported by ORTC.
>
>
>
> On Mon, Oct 20, 2014 at 2:58 AM, Sergio Garcia Murillo <
> sergio.garcia.murillo@gmail.com> wrote:
>
>>  Hi all,
>>
>> I am currently implementing the RTX RFC on my MCU, so I am a bit obsessed
>> with this topic.. :)
>>
>> I have been looking how ORTC implements it, and not really sure if
>> current API would allow to implement it.
>>
>> According to rfc588, it is possible to do to kind of
>>
>>    Session-multiplexing: scheme by which the original stream and the
>>    associated retransmission stream are sent into two different RTP
>>    sessions.
>>
>>    SSRC-multiplexing: scheme by which the original stream and the
>>    retransmission stream are sent in the same RTP session with different
>>    SSRC values.
>>
>>
>>
>> I am not yet an expert on ORTC apis, so please correct me if I am wrong,
>> but it seems that the only way to set/retrieve the ssrc of the stream is
>> via the RTCRtpParameters. So I think that in order to support
>> SSRC-multiplixing, it would be needed to change:
>>
>> dictionary RTCRtpParameters {    DOMString                                 muxId <http://ortc.org/wp-content/uploads/2014/10/ortc.html#widl-RTCRtpParameters-muxId> = "";    sequence<RTCRtpCodecParameters <http://ortc.org/wp-content/uploads/2014/10/ortc.html#idl-def-RTCRtpCodecParameters>>           codecs <http://ortc.org/wp-content/uploads/2014/10/ortc.html#widl-RTCRtpParameters-codecs>;    sequence<RTCRtpHeaderExtensionParameters <http://ortc.org/wp-content/uploads/2014/10/ortc.html#idl-def-RTCRtpHeaderExtensionParameters>> headerExtensions <http://ortc.org/wp-content/uploads/2014/10/ortc.html#widl-RTCRtpParameters-headerExtensions>;    sequence<RTCRtpEncodingParameters <http://ortc.org/wp-content/uploads/2014/10/ortc.html#idl-def-RTCRtpEncodingParameters>>        encodings <http://ortc.org/wp-content/uploads/2014/10/ortc.html#widl-RTCRtpParameters-encodings>;    RTCRtcpParameters <http://ortc.org/wp-content/uploads/2014/10/ortc.html#idl-def-RTCRtcpParameters>                         rtcp <http://ortc.org/wp-content/uploads/2014/10/ortc.html#widl-RTCRtpParameters-rtcp>;
>> };
>>
>> by
>>
>> dictionary RTCRtpParameters {    DOMString                                 muxId <http://ortc.org/wp-content/uploads/2014/10/ortc.html#widl-RTCRtpParameters-muxId> = "";    sequence<RTCRtpCodecParameters <http://ortc.org/wp-content/uploads/2014/10/ortc.html#idl-def-RTCRtpCodecParameters>>           codecs <http://ortc.org/wp-content/uploads/2014/10/ortc.html#widl-RTCRtpParameters-codecs>;    sequence<RTCRtpHeaderExtensionParameters <http://ortc.org/wp-content/uploads/2014/10/ortc.html#idl-def-RTCRtpHeaderExtensionParameters>> headerExtensions <http://ortc.org/wp-content/uploads/2014/10/ortc.html#widl-RTCRtpParameters-headerExtensions>;    sequence<RTCRtpEncodingParameters <http://ortc.org/wp-content/uploads/2014/10/ortc.html#idl-def-RTCRtpEncodingParameters>>        encodings <http://ortc.org/wp-content/uploads/2014/10/ortc.html#widl-RTCRtpParameters-encodings>;     <http://ortc.org/wp-content/uploads/2014/10/ortc.html#idl-def-RTCRtcpParameters>*sequence<RTCRtcpParameters <http://ortc.org/wp-content/uploads/2014/10/ortc.html#idl-def-RTCRtcpParameters>>               rtcps <http://ortc.org/wp-content/uploads/2014/10/ortc.html#widl-RTCRtpParameters-rtcp>;*
>> };
>>
>>
>> Regarding how to implement the Session-Multiplexing (if needed to), I
>> think it would be more complex, as it would require to add some kind of
>> RTCRtpSenderGroup and RTCRtpReceiverGroup objects that would make it
>> possible to group several sender/receivers together.
>>
>> Best regards
>> Sergio
>>
>>
>
>