Subject: [rtcweb] SDP and ssrc-group,

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 Oct 2014 18:25:38 +0200

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
<[email-masked]>

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 21 Oct 2014 10:31:01 -0700

345259865 is "real"
2693756249 is rtx

On Tue, Oct 21, 2014 at 9:25 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 Oct 2014 19:40:46 +0200

How is that? Where is that specified? What about if I include 3 ssrc values
in the ssrc-group? What is each one for?

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 21 Oct 2014 10:57:09 -0700

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 <[email-masked]> 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?

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Oct 2014 11:06:31 -0700

Looking at the SDP, the Payload Type seems like the clearest way to differentiate.  As it is, SSRC does not appear linked to the potential payloads.

> On Oct 21, 2014, at 10:40 AM, Iñaki Baz Castillo <[email-masked]> 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?
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 21 Oct 2014 20:31:26 +0200

Hi Peter,

This is the rtcweb list, so while I appreciate the info about how Chrome 
implements it, in regards to this discussion it is irrelevant. As far as 
I know there is no spec that allow us to know just by looking at the SDP 
which ssrc belongs to each stream. Please, correct me if I am wrong.

Best regards
Sergio
On 21/10/2014 19:57, Peter Thatcher wrote:
> 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 <[email-masked] 
> <mailto:[email-masked]>> 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" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         345259865 is "real"
>         2693756249 <tel:2693756249> is rtx
>
>         On Tue, Oct 21, 2014 at 9:25 AM, Iñaki Baz Castillo
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Hi,
>
>             May I know which SSRC (345259865 or 2693756249
>             <tel:2693756249>) will be used for the
>             a=ssrc-group:FID 345259865 2693756249 <tel:2693756249>
>             a=ssrc:2693756249 <tel:2693756249> cname:erS7E/KHLYKTejNs
>             a=ssrc:2693756249 <tel:2693756249>
>             msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>             a=ssrc:2693756249 <tel:2693756249>
>             mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>             a=ssrc:2693756249 <tel:2693756249>
>             label:c0134f05-e7c2-4afd-a979-4e224de5eb91
>             <[email-masked] <mailto:[email-masked]>>
>
>             [email-masked] <mailto:[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 Oct 2014 20:36:16 +0200

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?

---

From: Justin Uberti <[email-masked]>
Date: Tue, 21 Oct 2014 13:02:29 -0700

> Does not the above SDP look a complete mixture of hacks and workarounds?
Are you new here?

In all seriousness, it would be nice if this behavior was standardized, so
that applications could have deterministic behavior. If we can come up with
appropriate text about the ordering of SSRCs, this could be written into
JSEP's handling of setLocalDescription.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 21 Oct 2014 20:14:22 +0000

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?

<Raju >

Right. Firefox may have a different interpretation.

If a=ssrc-group and retransmissions are negotiated at SDP answer, then the order of ssrcs probably does not matter as the RTP payload values can determine the retransmission vs. original payloads.

If answerer wants to know the original ssrc for rejecting a=ssrc-group and retransmission payload then it need to know the original ssrc.

http://tools.ietf.org/html/rfc5576#section-6.3 defines a=ssrc with format. In the example below,

won’t having the following SDP line be sufficient to assign 2693756249<tel:2693756249> for retransmission and, indirectly, assign  345259865 for original .

a=ssrc:2693756249<tel:2693756249> fmtp:96

--------------------------
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: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<tel:2693756249> cname:erS7E/KHLYKTejNs
a=ssrc:2693756249<tel:2693756249> msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=ssrc:2693756249<tel:2693756249> mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=ssrc:2693756249<tel:2693756249> label:c0134f05-e7c2-4afd-a979-4e224de5eb91
-------------------------------

On the question of what if there are 3 ssrcs?

Per my understanding, there is only one ssrc for original payload and another for retransmission. So, a=ssrc-group containing 3 ssrcs is probably invalid.

</Raju>

BR

Raju

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 21 Oct 2014 22:49:25 +0200

On 21/10/2014 22:14, Makaraju, Maridi Raju (Raju) wrote:
> My question was generic: if I receive the above SDP, how do I know 
> which payloads each ssrc is supposed to transport?
>
> */<Raju >/*
>
> */Right. Firefox may have a different interpretation./*
>
> */If a=ssrc-group and retransmissions are negotiated at SDP answer, 
> then the order of ssrcs probably does not matter as the RTP payload 
> values can determine the retransmission vs. original payloads./*
>
> */If answerer wants to know the original ssrc for rejecting 
> a=ssrc-group and retransmission payload then it need to know the 
> original ssrc./*
>
> *//*
>
> */http://tools.ietf.org/html/rfc5576#section-6.3 defines a=ssrc with 
> format. In the example below,/*
>
> */won't having the following SDP line be sufficient to assign 
> 2693756249 <tel:2693756249> for retransmission and, indirectly, assign 
>  345259865 for original ./*
>
> */a=ssrc:2693756249 <tel:2693756249> fmtp:96 /*
>
> */On the question of what if there are 3 ssrcs?/*
>
> */Per my understanding, there is only one ssrc for original payload 
> and another for retransmission. So, a=ssrc-group containing 3 ssrcs is 
> probably invalid./*
>
> *//*
>
> */</Raju>/*
>
>
Hi Raju

I foresee that when we start working on FEC we will end up using a 
different ssrc to avoid asking retransmissions of FEC redundant data. So 
3 ssrcs will be needed for each media stream.

Regarding the ftmp ssrc attribute, syntactically it solves perfectly the 
problem (even if we have fec in its own ssrc), but I am not sure if 
semantically it is the intended usage, as it seems more to define format 
attributes for an specific ssrc an not to restrict the usage of the 
payload type to that ssrc.

Also, I am not sure how that would play together with plan c/plan b/plan 
c/no plan (I have not followed that thread actively).

Best regards
Sergio

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 22 Oct 2014 17:29:54 +0200

> JSEP's handling of setLocalDescription.

So I expect a new draft about how to map ssrc values and payload-types
in SDP. I think we already have 4 or 5 drafts about mapping or
grouping stuff in SDP, but it looks like having them is not enough to
define which payload-types are carried over each declared SSRC within
a transport or m line (or bundled m lines within the same transport
because what a m line represents is no longer clear).

Is that? do we need a new SDP draft? or is it enough if we create a
convention within the WebRTC context?

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 22 Oct 2014 16:06:22 +0000

Hi Sergio,

<Raju >

won't having the following SDP line be sufficient to assign 2693756249<tel:2693756249> for retransmission and, indirectly, assign  345259865 for original .

</Raju>

Hi Raju

I foresee that when we start working on FEC we will end up using a different ssrc to avoid asking retransmissions of FEC redundant data. So 3 ssrcs will be needed for each media stream.
<Raju2>
But for FEC, you will have to specify a different a=ssrc-group:FID. So, I think a=ssrc-group:FID will still have 2 ssrcs only.
</Raju2>

Regarding the ftmp ssrc attribute, syntactically it solves perfectly the problem (even if we have fec in its own ssrc), but I am not sure if semantically it is the intended usage, as it seems more to define format attributes for an specific ssrc an not to restrict the usage of the payload type to that ssrc.
<Raju2>
Whatever was the initial intended purpose, I think it can be put to use it for this (new) usage. By definition, retransmission payload can only be sent on one ssrc only and also the original payloads can only be sent on one ssrc only. So, assuming there is only one retransmission payload independent of  # of original payloads, just associating it to an ssrc unambiguously maps both ssrcs. But still, an explicit mapping for all ssrcs can also be done, thought which is unnecessary I think.
</Raju2>

BR
Raju

Also, I am not sure how that would play together with plan c/plan b/plan c/no plan (I have not followed that thread actively).

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 22 Oct 2014 18:13:20 +0200

On 22/10/2014 18:06, Makaraju, Maridi Raju (Raju) wrote:
> different ssrc to avoid asking retransmissions of FEC redundant data. 
> So 3 ssrcs will be needed for each media stream.
> */<Raju2> /*
>
> */But for FEC, you will have to specify a different a=ssrc-group:FID. 
> So, I think a=ssrc-group:FID will still have 2 ssrcs only./*
>
> */</Raju2>/*
>
Indeed, in fact I was proposing in another thread to use a the 
ssrc-group:FEC (and remove the RED altogether).

> Regarding the ftmp ssrc attribute, syntactically it solves perfectly 
> the problem (even if we have fec in its own ssrc), but I am not sure 
> if semantically it is the intended usage, as it seems more to define 
> format attributes for an specific ssrc an not to restrict the usage of 
> the payload type to that ssrc.
> */<Raju2>/*
>
> */Whatever was the initial intended purpose, I think it can be put to 
> use it for this (new) usage. By definition, retransmission payload can 
> only be sent on one ssrc only and also the original payloads can only 
> be sent on one ssrc only. So, assuming there is only one 
> retransmission payload independent of  # of original payloads, just 
> associating it to an ssrc unambiguously maps both ssrcs. But still, an 
> explicit mapping for all ssrcs can also be done, thought which is 
> unnecessary I think. /*
>
> */</Raju2>/*
>
I am also fine, just not sure if everyone else would agree.

Best regards
Sergio

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 22 Oct 2014 16:20:05 +0000

> in SDP. I think we already have 4 or 5 drafts about mapping or

<Raju>
Do we really need a new draft? or Won't the mechanism (a=ssrc:<ssrc> fmt:<payload>) mentioned in http://tools.ietf.org/html/rfc5576#section-6.3 be sufficient for this? (which is being discussed in this same thread)	
</Raju>

BR
Raju

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 22 Oct 2014 12:01:37 -0700

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:[email-masked] 
 a=ssrc:22222 cname:[email-masked] 
 a=ssrc-group:FID 33333 44444 
 a=ssrc:33333 cname:[email-masked] 
 a=ssrc:44444 cname:[email-masked]

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], 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]; 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 <[email-masked]> wrote:
> 
>> It only supports 2 SSRCs for a FID group.  It would ignore any more than that.
>>

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 22 Oct 2014 12:16:47 -0700

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 <[email-masked]>
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:
>
>
> 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.
>
>
>       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.
>
>
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 22 Oct 2014 12:28:59 -0700

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 <[email-masked]> 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 <[email-masked]> wrote:

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 22 Oct 2014 21:34:41 +0200

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 <[email-masked] 
> <mailto:[email-masked]>> 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 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     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:
>>
>>
>>       a=ssrc:11111 cname:[email-masked]  <http://example.com>  
>>
>>       a=ssrc:22222 cname:[email-masked]  <http://example.com>  
>>
>>       a=ssrc:33333 cname:[email-masked]  <http://example.com>  
>>
>>       a=ssrc:44444 cname:[email-masked]  <http://example.com>
>>
>>
>>       o=mascha 2980675221 2980675778 IN IP4host.example.net  <http://host.example.net>  
>>
>>       c=IN IP4 192.0.2.0
>>
>>     On Oct 21, 2014, at 11:36 AM, Iñaki Baz Castillo <[email-masked]
>>>     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" <[email-masked]
>>>         On Tue, Oct 21, 2014 at 10:40 AM, Iñaki Baz Castillo
>>>             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"
>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>                 345259865 is "real"
>>>                     <tel:2693756249>
>>>                     a=ssrc:345259865
>>>                     a=ssrc:345259865
>>>                     a=ssrc:345259865
>>>                     cname:erS7E/KHLYKTejNs

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 22 Oct 2014 12:39:50 -0700

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 <
[email-masked]> wrote:

> 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
>
> case. As long as payload types are distinct we have all the information we
> need.
>
> 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
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 22 Oct 2014 21:41:24 +0200

BTW, please, please, please, let's use the sssrc-group:FEC and send the 
FEC in its own ssrc stream, so we don't have to use RED anymore..

On 22/10/2014 21:01, Bernard Aboba wrote:
> 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:
>
>
>>         How is that? Where is that specified? What about if I include
>>         3 ssrc values in the ssrc-group? What is each one for?
>>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 22 Oct 2014 20:05:33 +0000

Just thinking loud

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.
<Raju>
For a simple SDP offer/answer case it is probably not needed. But think of a case where SDP answerer does not support a=ssrc-group:FID and also associated retransmission ‘apt’ payload then it will not include them in SDP answer. But it needs to know which ssrc is associated to the original payload so that it allows only that ssrc.

</Raju>

BR
Raju

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 22 Oct 2014 20:14:31 +0000

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

 a=rtpmap:96 H.264/90000

 a=rtpmap:98 rtx/90000

 a=ssrc:11111 cname:[email-masked]<http://example.com>

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

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

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

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.

 v=0

 o=mascha 2980675221 2980675778 IN IP4 host.example.net<http://host.example.net>

 c=IN IP4 192.0.2.0

 a=rtcp-fb:96 nack

 a=rtpmap:97 rtx/90000

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 <[email-masked]<mailto:[email-masked]>> wrote:

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" <[email-masked]<mailto:[email-masked]>> wrote:
I'm not sure where it's specified, but here's where it's implemented:

On Tue, Oct 21, 2014 at 10:40 AM, Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>> 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" <[email-masked]<mailto:[email-masked]>> wrote:
345259865 is "real"
2693756249<tel:2693756249> is rtx

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

May I know which SSRC (345259865 or 2693756249<tel:2693756249>) will be used for the
real media stream (plus RED and FEC) and which SSRC will be used for
RTX?

   [..]

--
Iñaki Baz Castillo
<[email-masked]<mailto:[email-masked]>>

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

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 22 Oct 2014 14:28:37 -0700

RFC 5576 makes it clear that partial rejection is not supported. 

> On Oct 22, 2014, at 1:14 PM, Makaraju, Maridi Raju (Raju) <[email-masked]> wrote:
> 
> RFC 5576 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:
>  
>  I believe that RFC 5577 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 5576 Section 8:
>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 22 Oct 2014 22:05:44 +0000

RFC 5576 makes it clear that partial rejection is not supported.
<Raju>
True, http://tools.ietf.org/html/rfc5576#section-8 did say that. Thanks for pointing it out.
Section 9 says the following; which still say there may be a need for explicit source descriptions are needed. The receiver does not understand this RFC 5576 so it would ignore unknown a=ssrc-group or rtx/apx payload. Then how does it know which ssrc (it does understand a=ssrc lines) is original?
9<http://tools.ietf.org/html/rfc5576#section-9>.  Backward Compatibility
   According to the definition of SDP, interpreters of SDP session
   descriptions ignore unknown attributes.  Thus, endpoints MUST be
   prepared that recipients of their RTP media session may not
   understand their explicit source descriptions, unless some external
   mechanism indicates that they were understood.  In some cases (such
   as RTP Retransmission [RFC4588<http://tools.ietf.org/html/rfc4588>]), this may constrain some choices
   about the bitstreams that are transmitted.

</Raju>

BR
Raju

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Wed, 22 Oct 2014 18:22:03 -0700

> FEC in its own ssrc stream, so we don't have to use RED anymore..

That may be fine for video, but the added header overhead for audio is 
substantial (and there are a number of other problems that RED solves 
there, as discussed at the last meeting).

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 23 Oct 2014 17:20:43 +0200

> there, as discussed at the last meeting).
Could you elaborate please?

Best regards
Sergio

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 23 Oct 2014 17:03:31 +0000

> there, as discussed at the last meeting).

<Raju>
I am not sure if red+ulpfec is used for audio codecs in webrtc context (in general it can be used for alternate encodings even for audio); OPUS does have a built-in FEC so no need for red+ulpfec.

For video, the RTP header overhead added by ssrc multiplexing is considerable (not significant, but can't be ignored) especially for the non-key frames and in mobile environments.
Also, there is an additional problem with ssrc multiplexing for FEC.
Use of red+ulpfec makes it easy for an SDP answerer to reject it by excluding red+ulpfec payloads if it does not support FEC. But use of a=ssrc-group:FEC makes it hard to reject the FEC part as the semantics are not supported by http://tools.ietf.org/html/rfc5576#section-8
This issue is being discussed at http://www.ietf.org/mail-archive/web/rtcweb/current/msg13249.html

While Chrome supports red+ulpfec Firefox does not (yet!). If we use a=ssrc-group:FEC then we will have an interop issue if Firefox rejects the entire video offer to strictly comply to RFC 5576 section 8.

I wish the draft-ietf-rtcweb-rtp-usage (draft-ietf-rtcweb-audio or draft-ietf-rtcweb-video) says one way or other about how to convey FEC encoding (redundant encoding or ssrc multiplexing) 

</Raju>

BR
raju

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Thu, 23 Oct 2014 10:12:05 -0700

Makaraju, Maridi Raju (Raju) wrote:
> OPUS does have a built-in FEC so no need for red+ulpfec.

As discussed previously on this list [1] the built-in FEC only covers 
the SILK layer. Existing codec-agnostic mechanisms were perfectly 
adequate for protecting CELT-mode packets, so we didn't invent something 
new.

[1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg12353.html

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Thu, 23 Oct 2014 10:19:59 -0700

> Could you elaborate please?

See slide 4 of 
<http://www.ietf.org/proceedings/90/slides/slides-90-rtcweb-7.pdf>. I 
was particularly thinking of the issues with bundle, which do not apply 
to RFC 2198 RED (which I pointed out at the mic).

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 23 Oct 2014 19:29:00 +0000

> [1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg12353.html
[Raju] Thanks and appreciate the reference.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 28 Oct 2014 21:23:34 -0700

So it's not clear to me that a=ssrc:X fmtp:Y is actually legal, without any
fmtp parameters, or that it clearly indicates that only PT Y is to be sent
on that SSRC. As such, I consider this solution to be wishful thinking.

I think it would be easier if we defined FEC/FID semantics such that the
initial SSRC was to be used for the primary encoding, and any subsequent
SSRCs were used for the secondary/tertiary streams. (e.g. RTX or FEC)

e.g. for a stream with 2 video codecs, RTX and 1d/2d FEC:

     m=video 30000 RTP/AVP 100 101 108 109 110 111
     c=IN IP4 233.252.0.1
     a=rtpmap:100 VP8/90000
     a=rtpmap:101 VP9/90000
     a=rtpmap:108 rtx/90000
     a=rtpmap:109 rtx/90000
     a=fmtp:108 apt=100
     a=fmtp:109 apt=101
     a=rtpmap:110 interleaved-parityfec/90000
     a=fmtp:110 L:5; D:10; ToP:2; repair-window:200000
     a=rtpmap:111 non-interleaved-parityfec/90000
     a=fmtp:111 L:5; D:10; ToP:2; repair-window:200000
     a=ssrc:1234
     a=ssrc:2345
     a=ssrc:3456
     a=ssrc:4567
     a=ssrc-group:FID 1234 2345
     a=ssrc-group:FEC-FR 1234 3456 4567

SSRC 1234 is the primary encoding (VP8 or VP9)
SSRC 2345 is RTX (either PT 108 or 109, as needed)
SSRC 3456 is FEC (either PT 110 or 111, depending on impl)
SSRC 4567 is FEC (either PT 110 or 111, depending on impl)

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Oct 2014 22:22:28 -0700

Sounds like a reasonable idea to me, but don't you have to specify a strict
pecking order? RTX before FEC doesn't sound right to me, but that's pure
prejudice/bias (FEC is always present, and optional stuff his last)

So how would you decide that order? A hat? PT value? Order of PT on the m
line? Order of the fmtp attributes? Something else? Or can we simply fix
the order, since there are only a small number of variations to consider?
On Oct 28, 2014 9:24 PM, "Justin Uberti" <[email-masked]> wrote:

> So it's not clear to me that a=ssrc:X fmtp:Y is actually legal, without
> any fmtp parameters, or that it clearly indicates that only PT Y is to be
> sent on that SSRC. As such, I consider this solution to be wishful thinking.
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 29 Oct 2014 05:51:05 +0000

I think Justin meant the “initial SSRC” in the a=ssrc-group lines carries significance (as the source), not the order of a=ssrc lines.

What if new FEC schemes defined for bundle / unified plan (such as those below) followed the example of RTX by including apt=100 in their fmtp parameters? So PT can be used to associate source and FEC flows without declaring any SSRCs or groups.

We can also improve on RTX by allowing apt=100,101 for FEC.

When we consider more complex cases like RTX/FEC with simulcast and scalable streams in unified plan, using PT association may be better than declaring many SSRCs (which is also problematic in cases of collisions, dynamic sources, switching mixers, etc.).

Mo

On 10/29/14, 1:22 AM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
Sounds like a reasonable idea to me, but don't you have to specify a strict pecking order? RTX before FEC doesn't sound right to me, but that's pure prejudice/bias (FEC is always present, and optional stuff his last)

So how would you decide that order? A hat? PT value? Order of PT on the m line? Order of the fmtp attributes? Something else? Or can we simply fix the order, since there are only a small number of variations to consider?

On Oct 28, 2014 9:24 PM, "Justin Uberti" <[email-masked]<mailto:[email-masked]>> wrote:
So it's not clear to me that a=ssrc:X fmtp:Y is actually legal, without any fmtp parameters, or that it clearly indicates that only PT Y is to be sent on that SSRC. As such, I consider this solution to be wishful thinking.

I think it would be easier if we defined FEC/FID semantics such that the initial SSRC was to be used for the primary encoding, and any subsequent SSRCs were used for the secondary/tertiary streams. (e.g. RTX or FEC)

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 28 Oct 2014 23:02:09 -0700

Am not against allowing 'apt' with FEC, but forcing a PT to be consumed for each FEC stream could get out of hand, particularly for combined simulcast/SVC cases. 

> On Oct 28, 2014, at 10:51 PM, Mo Zanaty (mzanaty) <[email-masked]> wrote:
> 
> On 10/29/14, 1:22 AM, Martin Thomson <[email-masked]> wrote:
>>> On Thu, Oct 23, 2014 at 12:29 PM, Makaraju, Maridi Raju (Raju) <[email-masked]> wrote:
>>> >

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Oct 2014 06:54:32 +0000

Hi,

>So how would you decide that order? A hat? PT value? Order of PT on the m line? Order of the fmtp attributes? Something else? Or can we simply fix the order, since there are only a small number of v…

Without commenting on this specific mechanism, in general we should NOT define solutions which assume a certain order of attributes (associated with a given m- line, or on session level) etc.

I have seen nodes, where the order of attributes has changed between the incoming- and outgoing SDP, due to the way the parser in the node is implemented.

I also don’t think we should change the semantics of the PT order in the m- line.

Regards,

Christer

---

From: "Roni Even" <[email-masked]>
Date: Wed, 29 Oct 2014 09:48:00 +0200

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:[email-masked]] On Behalf Of I?aki Baz Castillo
> Sent: 21 October, 2014 7:26 PM
> To: [email-masked]
> 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?
> 
> 
> 
> Does a ssrc-group always mean RTX usage? Where is that specified in the
> above SDP?
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 29 Oct 2014 13:10:05 +0100

Indeed, that was my original concern also.

Using the order of ssrc-ids on the ssrc-group may be the simplest way to 
solve it, but not sure if it would allow more complex FEC scenarios, 
like one FEC stream protecting two media flows (maybe not relevant at all).

I have been surfing at the ietf rfcs, and found and interesting one 
rfc6364 which defines  fec-source-flow and fec-repair-flow media 
attributes that can be used with a=group:FEC-FR, hat would allow exactly 
what we need:

         v=0
         o=ali 1122334455 1122334466 IN IP4 fec.example.com
         s=FEC Framework Examples
         t=0 0
         a=group:FEC-FR S1 R1
         m=video 30000 RTP/AVP 100
         c=IN IP4 233.252.0.1/127
         a=rtpmap:100 MP2T/90000
         a=fec-source-flow: id=0
         a=mid:S1
         m=application 30000 UDP/FEC
         c=IN IP4 233.252.0.2/127
         a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
         a=repair-window:150ms
         a=mid:R1

We would need to port thatould neerc-group semantics, like for example

      m=video 30000 RTP/AVP 100 101 108 109 110 111
      c=IN IP4 233.252.0.1
      a=rtpmap:100 VP8/90000
      a=rtpmap:101 VP9/90000
      a=rtpmap:108 rtx/90000
      a=rtpmap:109 rtx/90000
      a=fmtp:108 apt=100
      a=fmtp:109 apt=101
      a=rtpmap:110 interleaved-parityfec/90000
      a=fmtp:110 L:5; D:10; ToP:2; repair-window:200000
      a=rtpmap:111 non-interleaved-parityfec/90000
      a=fmtp:111 L:5; D:10; ToP:2; repair-window:200000
      a=ssrc:1234 fec-source-flow: id=0
      a=ssrc:2345
      a=ssrc:3456 fec-repair-flow: encoding-id=0;
      a=ssrc:4567 fec-repair-flow: encoding-id=0;
      a=ssrc-group:FID 1234 2345
      a=ssrc-group:FEC-FR 1234 3456 4567

Best regards
Sergio
On 29/10/2014 5:23, Justin Uberti wrote:
> So it's not clear to me that a=ssrc:X fmtp:Y is actually legal, 
> without any fmtp parameters, or that it clearly indicates that only PT 
> Y is to be sent on that SSRC. As such, I consider this solution to be 
> wishful thinking.
>
> I think it would be easier if we defined FEC/FID semantics such that 
> the initial SSRC was to be used for the primary encoding, and any 
> subsequent SSRCs were used for the secondary/tertiary streams. (e.g. 
> RTX or FEC)
>
> On Thu, Oct 23, 2014 at 12:29 PM, Makaraju, Maridi Raju (Raju) 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     >
>     > [1]
>     https://www.ietf.org/mail-archive/web/rtcweb/current/msg12353.html

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 29 Oct 2014 12:24:13 +0000

<Raju>

I agree with the above comments. AFAIK, SDP has session level and media level semantics, but no order (of a= lines) based semantics.

I also agree that “a=ssrc:<ssrc> fmtp:<format#>” does not give a clear answer.

How about extending http://tools.ietf.org/html/rfc5576#section-6.3 to add a new “fmtps” to associate allowed formats to an ssrc and define semantics unambiguously? Justin’s example would become like this:

     m=video 30000 RTP/AVP 100 101 108 109 110 111
     c=IN IP4 233.252.0.1
     a=rtpmap:100 VP8/90000
     a=rtpmap:101 VP9/90000
     a=rtpmap:108 rtx/90000
     a=rtpmap:109 rtx/90000
     a=fmtp:108 apt=100
     a=fmtp:109 apt=101
     a=rtpmap:110 interleaved-parityfec/90000
     a=fmtp:110 L:5; D:10; ToP:2; repair-window:200000
     a=rtpmap:111 non-interleaved-parityfec/90000
     a=fmtp:111 L:5; D:10; ToP:2; repair-window:200000
     a=ssrc:1234 fmtps:100,101
     a=ssrc:2345 fmtps:108,109
     a=ssrc:3456 fmtps:110,111
     a=ssrc:4567 fmtps:110,111
     a=ssrc-group:FID 1234 2345
     a=ssrc-group:FEC-FR 1234 3456 4567

The fmtps mappings give the following associations:

</Raju>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 29 Oct 2014 13:30:22 +0100

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

---

From: "Roni Even" <[email-masked]>
Date: Wed, 29 Oct 2014 17:14:11 +0200

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

> From: rtcweb [mailto:[email-masked]] On Behalf Of Sergio Garcia
> Murillo
> Sent: 29 October, 2014 2:30 PM
> To: [email-masked]
> 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
> > 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
> >
> >> 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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 29 Oct 2014 16:21:44 +0100

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

---

From: Justin Uberti <[email-masked]>
Date: Wed, 29 Oct 2014 12:34:33 -0700

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 <
[email-masked]> wrote:

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