Re: [rtcweb] SDP and ssrc-group,

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

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.
<Raju>
What if the answerer wants to reject a=ssrc-group:FID (and a=fmtp:98 apt=96;rtx-time=3000) then which of the two ssrcs it can expect to receive for the original transmission?
</Raju>

BR
Raju

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]<http://example.com>

 a=ssrc:22222 cname:[e-mail]<http://example.com>

 a=ssrc-group:FID 33333 44444

 a=ssrc:33333 cname:[e-mail]<http://example.com>

 a=ssrc:44444 cname:[e-mail]<http://example.com>


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<http://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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> wrote:
345259865 is "real"
2693756249<tel:[phone]> is rtx

On Tue, Oct 21, 2014 at 9:25 AM, Iñaki Baz Castillo <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

May I know which SSRC (345259865 or 2693756249<tel:[phone]>) 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<tel:[phone]>
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<tel:[phone]> cname:erS7E/KHLYKTejNs
a=ssrc:2693756249<tel:[phone]> msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=ssrc:2693756249<tel:[phone]> mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=ssrc:2693756249<tel:[phone]> 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]<mailto:[e-mail]>>

_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb


_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb