Re: [rtcweb] SDP and ssrc-group,

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

Hi Sergio,


On 21/10/2014 22:14, Makaraju, Maridi Raju (Raju) 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?

<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:[phone]> for retransmission and, indirectly, assign  345259865 for original .

a=ssrc:2693756249<tel:[phone]> 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:[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
-------------------------------

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