Re: [rtcweb] SDP and ssrc-group,

[Sergio Garcia Murillo <[e-mail]>]

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?
>>>>
>>>>
>>>>
>>>>
>>>> -