Subject: [rtcweb] How to signal RTX SSRCs with simulcast

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 9 Mar 2017 23:26:49 +0100

Hi,

According to the simulcast spec [1], when using simulcast the media
SSRCs are not signaled into the SDP but just the RID (RtpStreamId)
values of each media stream. For example:

---------------------------
a=rid:1 send
a=rid:2 send
a=simulcast: send rid=1;2
---------------------------

So when the remote peer receives a RTP packet, it checks the RID
header extension and learns its media SSRC.

In case RTX is used, each simulcast stream will have an associated RTX
stream and ssrc. RTX is signaled in a non very "cool" way by using the
a=ssrc-group:FID line:

a=ssrc-group:FID 1111 2222

(theoretically, 1111 is the media SSRC and 2222 is the RTX SSRC, but
who knows?).

So, how to signal the RTX SSRCs with 2 simulcast streams?

As a side note, current Firefox (which does not implement RTX yet)
also announces the media SSRCs of all the simulcast streams:

---------------------------
a=rid:1 send
a=rid:2 send
a=simulcast: send rid=1;2
a=ssrc:1589989957 cname:{4783b6ed-5282-8340-affe-a5e4c1f41993}
a=ssrc:2091640471 cname:{4783b6ed-5282-8340-affe-a5e4c1f41993}
---------------------------

Still the remote peer must look at the RID header extension of the
received RTP packet in order to learn its media SSRC.

In case RTX is used for each simulcast stream, would the following
syntax the correct way to go?:

---------------------------
a=rid:1 send
a=rid:2 send
a=simulcast: send rid=1;2
a=ssrc:1111 cname:{4783b6ed-5282-8340-affe-a5e4c1f41993}
a=ssrc:2222 cname:{4783b6ed-5282-8340-affe-a5e4c1f41993}
a=ssrc:3333 cname:{4783b6ed-5282-8340-affe-a5e4c1f41993}
a=ssrc:4444 cname:{4783b6ed-5282-8340-affe-a5e4c1f41993}
a=ssrc-group:FID 1111 3333
a=ssrc-group:FID 2222 4444
---------------------------

so, 1111 is the SSRC of the first media stream, 2222 is the SSRC of
the second media stream, 3333 is the SSRC of the RTX for the first
media stream, and 4444 is the SSRC of the RTX for the second media
stream.

Does it make sense?

[1] https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-07

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 09 Mar 2017 23:50:17 +0000

Why bother with signaling SSRCs?  RIDs obviate the need for signaling
SSRCs.  Just include the RID in the RTX packet.

On Thu, Mar 9, 2017 at 2:27 PM Iñaki Baz Castillo <[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 10 Mar 2017 00:52:42 +0100

2017-03-10 0:50 GMT+01:00 Peter Thatcher <[email-masked]>:
> Why bother with signaling SSRCs?  RIDs obviate the need for signaling SSRCs.
> Just include the RID in the RTX packet.

Sure. I just don't know whether, in simulcast, the RID extension
header is set into *every* RTP packet or not.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 10 Mar 2017 01:19:02 +0100

2017-03-10 1:17 GMT+01:00 Peter Thatcher <[email-masked]>:
> To be more specifc, JSEP specifically defers this to ietf-mmusic-rid:
>
> if the RID header extension has been
>          negotiated, and RID values are specified, include the RID
>          header extension in the outgoing RTP streams, as indicated in
>          [I-D.ietf-mmusic-rid], Section 4.

Thanks. I confirm that Firefox sets RID into every packet, so I expect
they'll also do that into RTX packets (when implemented).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 10 Mar 2017 00:17:17 +0000

if the RID header extension has been
         negotiated, and RID values are specified, include the RID
         header extension in the outgoing RTP streams, as indicated in
         [I-D.ietf-mmusic-rid
<https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-18#ref-I-D.ietf-mmusic-rid>],
Section 4.

On Thu, Mar 9, 2017 at 4:07 PM Peter Thatcher <[email-masked]> wrote:

> That's probably not a question for rtcweb, so I think we should remove
> them from the thread  (after this email :).  That's a question for
> mmusic, both in the context of draft-ietf-mmusic-sdp-simulcast
> and draft-ietf-mmusic-rid.
>
>
> On Thu, Mar 9, 2017 at 3:53 PM Iñaki Baz Castillo <[email-masked]> wrote:
>

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 10 Mar 2017 00:07:07 +0000

That's probably not a question for rtcweb, so I think we should remove them
from the thread  (after this email :).  That's a question for mmusic, both
in the context of draft-ietf-mmusic-sdp-simulcast and draft-ietf-mmusic-rid.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 10 Mar 2017 08:49:38 +0100

> SSRCs.  Just include the RID in the RTX packet. 
How does one know from the SDP that RTX is active if there are no
a=ssrc-group:FID lines?
(I'd be happy to see an answer like "a=rid:1 send rtx", but I would
really want to feel reassured that this is not a rabbit hole of infinite
dimension....)

>
> On Thu, Mar 9, 2017 at 2:27 PM Iñaki Baz Castillo <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     <[email-masked] <mailto:[email-masked]>>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 10 Mar 2017 11:31:15 +0100

> How does one know from the SDP that RTX is active if there are no

I don't think that RTX usage is declared by signaling the
ssrc-group:FID line but, instead, by providing the corresponding RTX
codec with the appropriate 'apt' value.

> (I'd be happy to see an answer like "a=rid:1 send rtx", but I would really
> want to feel reassured that this is not a rabbit hole of infinite
> dimension....)

IMHO, as far as RTX packets include the same RID header extension
value as the media stream they protect, we are fine. However, usually
RTP header extensions are just placed in the first N RTP packets. This
is just about setting the RID extension into the first N packets of
the RTX stream (and we are done).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 10 Mar 2017 12:37:25 -0700

I've got a suggestion on how to solve this. 

First imagine an endpoint with two video streams, one low res and one high but not simulcast and no RTX. Write down sketch of key parts of what SDP looks like for that. Call that example base. Now write down what SDP looks like if you add RTX to that example. Now write down what SDP looks like if you take the base and add simulcast to that (but still no RTX). At this point try the example with both RTX and simulcast. It seems to me if you just do what the drafts already say you get a soltuion that works but perhpas I am missing something. Etierh way, I think have the three examples of base, base+RTX, and base+simulcast would make it much easier to figure out what base+RTC+simulcast should look like. 

> On Mar 9, 2017, at 3:26 PM, Iñaki Baz Castillo <[email-masked]> wrote:
> 
> Hi,
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 10 Mar 2017 20:50:46 +0100

If no simulcast, those two video streams are in different m=video sections,
right?

El 10/3/2017 20:37, "Cullen Jennings" <[email-masked]> escribió:

> First imagine an endpoint with two video streams, one low res and one high
> but not simulcast and no RTX. Write down sketch of key parts of what SDP
> looks like for that. Call that example base. Now write down what SDP looks
> like if you add RTX to that example. Now write down what SDP looks like if
> you take the base and add simulcast to that (but still no RTX). At this
> point try the example with both RTX and simulcast. It seems to me if you
> just do what the drafts already say you get a soltuion that works but
> perhpas I am missing something. Etierh way, I think have the three examples
> of base, base+RTX, and base+simulcast would make it much easier to figure
> out what base+RTC+simulcast should look like.
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 10 Mar 2017 15:54:07 -0700

> On Mar 10, 2017, at 12:50 PM, Iñaki Baz Castillo <[email-masked]> wrote:
> 
> If no simulcast, those two video streams are in different m=video sections, right?
> 

yes

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 10 Mar 2017 23:56:54 +0100

> yes

I think that your example does not "work" well since simulcast is
achieved within a single m=video section.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Taylor Brandstetter <[email-masked]>
Date: Fri, 10 Mar 2017 15:17:33 -0800

What question are we still trying to answer? "How do we know that RTX is
active"? I think Iñaki already gave the right answer earlier: if the
endpoints negotiate an RTX "media format" ("a=rtpmap:96 rtx/90000"), each
endpoint should be prepared to receive RTX packets for any encoding.

And if the "rid" line explicitly specifies what payload types are allowed
to be used with that RID, it just needs to include the RTX payload type to
allow RTX to be used. Like so:

a=rtpmap:96 VP8/90000
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rid:foo send pt=96,97

But JSEP doesn't say "pt=" should be used, so I don't think this is even a
concern.

---

From: Bo Burman <[email-masked]>
Date: Mon, 13 Mar 2017 09:57:42 +0000

I’ve started a thread on MMUSIC list and suggest we continue the detailed discussion there.

/Bo

From: rtcweb [mailto:[email-masked]] On Behalf Of Taylor Brandstetter
Sent: den 11 mars 2017 00:18
To: Iñaki Baz Castillo <[email-masked]>
Cc: RTCWeb IETF <[email-masked]>; [email-masked]
Subject: Re: [rtcweb] How to signal RTX SSRCs with simulcast

What question are we still trying to answer? "How do we know that RTX is active"? I think Iñaki already gave the right answer earlier: if the endpoints negotiate an RTX "media format" ("a=rtpmap:96 rtx/90000"), each endpoint should be prepared to receive RTX packets for any encoding.

And if the "rid" line explicitly specifies what payload types are allowed to be used with that RID, it just needs to include the RTX payload type to allow RTX to be used. Like so:

a=rtpmap:96 VP8/90000
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rid:foo send pt=96,97

But JSEP doesn't say "pt=" should be used, so I don't think this is even a concern.

On Fri, Mar 10, 2017 at 2:56 PM, Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>> wrote:

--
Iñaki Baz Castillo
<[email-masked]<mailto:[email-masked]>>
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb