Re: [rtcweb] SDP and ssrc-group,

[Justin Uberti <[e-mail]>]

Correlation of RTP flow to m= line is being done by the mid header
extension. Correlation of an individual RTP flow to its 'role' (e.g. FEC,
RTX) within a m= line can be inferred from received data (e.g. either FEC
or RTX), or determined explicitly from a=ssrc-group attributes, perhaps
with the addition of some additional meta-information.

To be absolutely clear, I was trying to suggest that the first SSRC in an
a=ssrc-group line should indicate the primary stream, and subsequent ones
the secondary streams (e.g. FID/FEC). I was not trying to suggest any other
ordering within the SDP has any bearing on this question.

On Wed, Oct 29, 2014 at 8:21 AM, Sergio Garcia Murillo <
[e-mail]> wrote:

> Hi Roni,
>
> I agree that knowing ssrcs in the SDP is a burden, but it is not only
> related to FEC/RTX. IMHO that should be handled in Plan A/B/C/whatever
> discussions which I have to confess that have not been actively following.
>
> Best regards
> Sergio
>
> On 29/10/2014 16:14, Roni Even wrote:
>
>> Hi,
>> In the application token proposal we were trying to address two FEC
>> issues:
>>
>> 1. You assume that the SDP layer will know the SSRCs of the streams when
>> making an offer. This may be true for point to point call but there are
>> topologies (https://tools.ietf.org/html/draft-ietf-avtcore-rtp-
>> topologies-update-04) where the SSRCs may not be known to a Mixer who
>> projects incoming RTP streams as is. This was the reason for the
>> application token. (this is a general issue with other use cases when using
>> SSRC in SDP and bundle tried to address part of it for identifying the
>> received RTP streams using the SDP group mid values)
>>
>> 2. For this case instead of using ssrc-group we proposed appId-group and
>> define the mapping between an appId and the pt number to help identify the
>> relation in the SDP between the FEC streams and the source streams.
>>
>>
>> We had the feeling that the using the SSRC in SDP was causing multiple
>> issues and by using a token that does not have an RTP layer semantics we
>> can have a cleaner solution.
>>
>>
>> Roni
>>
>>  -----Original Message-----
>>> From: rtcweb [mailto:[e-mail]] On Behalf Of Sergio Garcia
>>> Murillo
>>> Sent: 29 October, 2014 2:30 PM
>>> To: [e-mail]
>>> Subject: Re: [rtcweb] SDP and ssrc-group,
>>>
>>>   From a formal perspective, I don't feel it is correct to describe the
>>> semantical
>>> meaning of an ssrc by referring to a payload.
>>>
>>> Best regards
>>> Sergio
>>> On 29/10/2014 8:48, Roni Even wrote:
>>>
>>>> Hi,
>>>> We discussed this mapping issue in a previous version of the
>>>> application token
>>>>
>>> draft http://tools.ietf.org/html/draft-even-mmusic-application-token-02
>>> example in section 1.
>>>
>>>> We thought of having a mapping from appId to "pt" (section 3.3.1) Roni
>>>>
>>>>  -----Original Message-----
>>>>> From: rtcweb [mailto:[e-mail]] On Behalf Of I?aki Baz
>>>>> Castillo
>>>>> Sent: 21 October, 2014 7:26 PM
>>>>> To: [e-mail]
>>>>> Subject: [rtcweb] SDP and ssrc-group,
>>>>>
>>>>> Hi,
>>>>>
>>>>> May I know which SSRC (345259865 or 2693756249) will be used for the
>>>>> real media stream (plus RED and FEC) and which SSRC will be used for
>>>>> RTX?
>>>>>
>>>>>
>>>>>
>>>>> --------------------------
>>>>> 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
>>>>> -------------------------------
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> RFC 5576 does not clarify it at all:
>>>>>
>>>>> http://tools.ietf.org/html/rfc5576#section-4.2
>>>>>
>>>>> --------------------------------------------------
>>>>> 4.2.  The "ssrc-group" Media Attribute
>>>>>
>>>>>      a=ssrc-group:<semantics> <ssrc-id> ...
>>>>>
>>>>>      [..]
>>>>>
>>>>>      The <semantics> parameter is taken from the specification of the
>>>>>      "group" attribute [RFC3388].  The initial semantic values defined
>>>>> for
>>>>>      the "ssrc-group" attribute are FID (Flow Identification) [RFC3388]
>>>>>      and FEC (Forward Error Correction) [RFC4756].  In each case, the
>>>>>      relationship among the grouped sources is the same as the
>>>>>      relationship among corresponding sources in media streams grouped
>>>>>      using the SDP "group" attribute.
>>>>> --------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>> The referenced RFC 3388 neither clarifies it:
>>>>>
>>>>> ---------------------------------------------------
>>>>> 7.4 FID Semantics
>>>>>
>>>>>      Several "m" lines grouped together using FID semantics form a
>>>>> media
>>>>>      flow.  A media agent handling a media flow that comprises several
>>>>> "m"
>>>>>      lines MUST send a copy of the media to every "m" line part of the
>>>>>      flow as long as the codecs and the direction attribute present in
>>>>> a
>>>>>      particular "m" line allow it.
>>>>>
>>>>>      It is assumed that the application uses only one codec at a time
>>>>> to
>>>>>      encode the media produced.  This codec MAY change dynamically
>>>>> during
>>>>>      the session, but at any particular moment only one codec is in
>>>>> use.
>>>>>
>>>>>      The application encodes the media using the current codec and
>>>>> checks
>>>>>      one by one all the "m" lines that are part of the flow.  If a
>>>>>      particular "m" line contains the codec being used and the
>>>>> direction
>>>>>      attribute is "sendonly" or "sendrecv", a copy of the encoded
>>>>> media is
>>>>>      sent to the address/port specified in that particular media
>>>>> stream.
>>>>>      If either the "m" line does not contain the codec being used or
>>>>> the
>>>>>      direction attribute is neither "sendonly" nor "sendrecv", nothing
>>>>> is
>>>>>      sent over this media stream.
>>>>> ----------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> So, how is the usage of ssrc-group? Where is it really defined?
>>>>>
>>>>> Can I put more than 2 ssrc together in the same ssrc-group line?
>>>>>
>>>>> How should the receiver interpret it?
>>>>>
>>>>> Does a ssrc-group always mean RTX usage? Where is that specified in the
>>>>> above SDP?
>>>>>
>>>>> Does not the above SDP look a complete mixture of hacks and
>>>>> workarounds?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -
>>>>>
>>>>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>