Re: RTX support (RFC 4588)

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.

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.

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 
> <mailto: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:
>
>     dictionaryRTCRtpParameters  {
>          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
>
>     dictionaryRTCRtpParameters  {
>          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
>
>

Received on Tuesday, 21 October 2014 08:15:34 UTC