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

["Roni Even" <[e-mail]>]

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]
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]>; [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]
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] and a=sscr:yyy 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