Re: [MMUSIC] RFC5576 support in draft-ietf-mmusic-sdp-simulcast-06

[Bo Burman <[e-mail]>]

Hi Roni,

I thought it was, but when looking a bit more closely it is clear that it is not allowed.
It would still be possible to use source-specific signaling and simulcast independently from one another, but it would not be possible to tell from the SDP which SSRC a specific simulcast stream will have. As said, one way to solve that could be to define source-specific usage of a=rid.

/Bo

From: Roni Even [mailto:[e-mail]]
Sent: den 16 november 2016 11:43
To: Bo Burman <[e-mail]>; 'Adam Roach' <[e-mail]>; [e-mail]
Subject: RE: [MMUSIC] RFC5576 support in draft-ietf-mmusic-sdp-simulcast-06

Hi Bo,
Are you sure it is allowed to use a=ssrc:<x> fmtp:<p> without any format specific parameters?
Roni

From: Bo Burman [mailto:[e-mail]]
Sent: Tuesday, November 08, 2016 3:30 PM
To: Roni Even; 'Adam Roach'; [e-mail]<mailto:[e-mail]>
Subject: RE: [MMUSIC] RFC5576 support in draft-ietf-mmusic-sdp-simulcast-06

Hi Roni,

When would it be necessary to use “a=ssrc” to associate an SSRC with a particular simulcast stream already on SDP level?

Whenever the first RTCP SR is sent for a simulcast stream, it will contain both the SSRC reported on and an RtpStreamId SDES item, which uniquely associates that SSRC to an “a=rid” line. If the RTP SDES header extension is used, RtpStreamId can also be in RTP header extensions. Both methods should allow making this SSRC-to-RtpStreamId association before or at reception of the first RTP packet.

What “it is possible, but not required to use source-specific signaling” meant to say was that use of “a=ssrc” is not needed for use with “a=simulcast” (or “a=rid”), but also not conflicting with other (non-simulcast-related) usages of “a=ssrc”.

If you really want to use a static “a=ssrc” to RtpStreamId mapping in SDP, you can use a 1:1 mapping between RTP payload type and RtpStreamId (not same value, but a 1:1 mapping). It should, for example, be possible to use an SDP like:

a=ssrc:<x> cname:<c>
a=ssrc:<x> fmtp:<p>
a=rid:<r> pt=<p>

If “a=rid” was to be defined as source-level attribute (which it currently is not), you could maybe also use:
a=ssrc:<x> cname:<c>
a=ssrc:<x> rid:<r>
a=rid:<r> …

Cheers,
/Bo

From: mmusic [mailto:[e-mail]] On Behalf Of Roni Even
Sent: den 3 november 2016 17:12
To: 'Adam Roach' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [MMUSIC] RFC5576 support in draft-ietf-mmusic-sdp-simulcast-06

Hi,
I am not sure how rid allows you to define an SSRC in the SDP and know in the SDP which SSRC is tied to each RTP payload subtype number explicitly.
Roni

From: Adam Roach [mailto:[e-mail]]
Sent: Wednesday, November 02, 2016 10:00 PM
To: Roni Even; [e-mail]<mailto:[e-mail]>
Subject: Re: [MMUSIC] RFC5576 support in draft-ietf-mmusic-sdp-simulcast-06

On 11/2/16 13:07, Roni Even wrote:
Hi,

I noticed that section 5 state that “It is possible, but not required to use source-specific signaling [RFC5576<https://tools.ietf.org/html/rfc5576>] with the proposed solution.”



I was wondering what does it mean since if I try to add a=ssrc   to the example in 6.6.1, there will be two a=sscr:xxx cname:[e-mail]<mailto:cname:[e-mail]> and a=sscr:yyy canme:[e-mail]<mailto:canme:[e-mail]> but it is not clear which ssrc is the HD and which is the thumbnail

That's what RID is for.

/a