Re: [rtcweb] SDP and ssrc-group,

[Peter Thatcher <[e-mail]>]

Most of the discussion here has been about having enough information to
receive packets.  But there's another side to it in the rtcweb case.  When
viewed as an API surface, having SDP that the JS gives to the browser which
means "use one of these for RTX, and one for the normal media flow, but you
pick which" is suboptimal.  As an API surface, it would be much better to
allow the application to be explicit about which SSRC it wants for which.



On Wed, Oct 22, 2014 at 12:34 PM, Sergio Garcia Murillo <
[e-mail]> wrote:

>  Hi,
>
> I disagree, It is not possible just by looking at the SDP to know which
> ssrc is from the media and which is from rtx. While for WebRTC-endpoints it
> may be irrelevant because, as you say, you can wait for the RTP data to
> check the payload type and match the ssrc, we have seen that it is a must
> have for interoperability with ORTC.
>
> Best regards
> Sergio
>
> On 22/10/2014 21:28, Bernard Aboba wrote:
>
> I agree. The SSRC-groups are included only to make it clear which
> FEC/RED/RTX streams go with which media streams in the multiple source
> case. As long as payload types are distinct we have all the information we
> need.
>
>  On Oct 22, 2014, at 12:16 PM, Suhas Nandakumar <[e-mail]>
> wrote:
>
>   Just thinking loud
>  As long as there is enough information to unabigously map the incoming
> streams to the SDP, i dont see we need any more information to be added.
>
>  I feel the combination of SSRC and Payload Type in the RTP packet is
> good enough to find the mapping to the appropriate media line (if the PTs
> are not repeated) when needed.
>
>  So in the initial examples above, ssrc-group communicated in SDP along
> with semantics (FEC,FID) when applied to incoming SSRCs and the associated
> payload type has all the needed info for the receiver to demux at the rtp
> level as well as map at the SDP level. Thus i dont see a need for
> specifying PT association explicitly in SDP for the ssrc-groups.
>
>  Cheers
> Suhas
>
> On Wed, Oct 22, 2014 at 12:01 PM, Bernard Aboba <[e-mail]>
> wrote:
>
>>  SDP specifies payload types for RED/ULPFEC/RTX so as to allow
>> differentiation within an ssrc-group. So while an fmtp: attribute could be
>> used to denote a media stream on an a:ssrc line, it is not necessary.
>>
>>  RFC 5176 Example 3 gives an example with two cameras in which there are
>> two ssrc-group lines (one for each camera), with payload type used to
>> differentiate between H.264 and RTX in each ssrc-group:
>>
>>
>>    m=video 49174 RTP/AVPF 96 98
>>
>>  a=rtpmap:96 H.264/90000
>>
>>  a=rtpmap:98 rtx/90000
>>
>>  a=fmtp:98 apt=96;rtx-time=3000
>>
>>  a=ssrc-group:FID 11111 22222
>>
>>  a=ssrc:11111 cname:[e-mail]
>>
>>  a=ssrc:22222 cname:[e-mail]
>>
>>  a=ssrc-group:FID 33333 44444
>>
>>  a=ssrc:33333 cname:[e-mail]
>>
>>  a=ssrc:44444 cname:[e-mail]
>>
>>  I believe that RFC 5176 includes the two groups to make clear that there are two sources so that the Answerer might choose to reject the m-line if it cannot handle that. From RFC 5176 Section 8:
>>
>>  When used with the SDP Offer/Answer Model [RFC3264 <http://tools.ietf.org/html/rfc3264>], SDP source-specific attributes describe only the sources that each party is
>>    willing to send (whether it is sending RTP data or RTCP report
>>    blocks).  No mechanism is provided by which an answer can accept or
>>    reject individual sources within a media stream; if the set of
>>    sources in a media stream is unacceptable, the answerer's only option
>>    is to reject the media stream or the entire multimedia session.
>>
>>  Note that in the example in RFC 4588 Section 8.8 where there is only one source, there are no ssrc-group lines at all:
>>
>>   v=0
>>
>>  o=mascha 2980675221 2980675778 IN IP4 host.example.net
>>
>>  c=IN IP4 192.0.2.0
>>
>>  m=video 49170 RTP/AVPF 96 97
>>
>>  a=rtpmap:96 MP4V-ES/90000
>>
>>  a=rtcp-fb:96 nack
>>
>>  a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F
>>
>>  a=rtpmap:97 rtx/90000
>>
>>  a=fmtp:97 apt=96;rtx-time=3000
>>
>>
>>  The situation would be the same for FEC groups created via
>> ssrc-group:FEC. From
>> https://tools.ietf.org/html/draft-lennox-payload-ulp-ssrc-mux  :
>>
>>        The FEC and the payload MAY also be multiplexed by SSRC into one
>>       single RTP session, with separate SSRC values, if the association
>>       between FEC and payload streams are communicated to all members of
>>       the session.  If SDP is used, this association MAY be communicated
>>       through the FEC ssrc-group semantic [RFC5576 <https://tools.ietf.org/html/rfc5576>]; other mechanisms
>>       are also possible.  Receivers MUST NOT attempt to interpret FEC
>>       streams for which they do not have information to associate them
>>       with the corresponding payload streams.
>>
>>
>>
>>
>> On Oct 21, 2014, at 11:36 AM, Iñaki Baz Castillo <[e-mail]> wrote:
>>
>>   I hope I can rule my SDP logic based on standards rather than on how
>> Chrome implements some features.
>>
>> My question was generic: if I receive the above SDP, how do I know which
>> payloads each ssrc is supposed to transport?
>> On 21 Oct 2014 19:57, "Peter Thatcher" <[e-mail]> wrote:
>>
>>>  I'm not sure where it's specified, but here's where it's implemented:
>>>
>>>
>>> https://code.google.com/p/webrtc/source/browse/trunk/talk/media/webrtc/webrtcvideoengine.cc#4108
>>>
>>>  It only supports 2 SSRCs for a FID group.  It would ignore any more
>>> than that.
>>>
>>> On Tue, Oct 21, 2014 at 10:40 AM, Iñaki Baz Castillo <[e-mail]>
>>> wrote:
>>>
>>>> How is that? Where is that specified? What about if I include 3 ssrc
>>>> values in the ssrc-group? What is each one for?
>>>>  On 21 Oct 2014 19:31, "Peter Thatcher" <[e-mail]> wrote:
>>>>
>>>>>  345259865 is "real"
>>>>>  2693756249 is rtx
>>>>>
>>>>> On Tue, Oct 21, 2014 at 9:25 AM, Iñaki Baz Castillo <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> 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?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Iñaki Baz Castillo
>>>>>> <[e-mail]>
>>>>>>
>>>>>> _______________________________________________
>>>>>> rtcweb mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>>
>>>>>
>>>>>
>>>    _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>
>
> _______________________________________________
> rtcweb mailing [e-mail]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>