Re: [rtcweb] SDP and ssrc-group,

"Makaraju, Maridi Raju (Raju)" <> Wed, 22 October 2014 16:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5F4D01ACDD3 for <>; Wed, 22 Oct 2014 09:06:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.709
X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bOVAw4Djk1HK for <>; Wed, 22 Oct 2014 09:06:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C7471ACDCC for <>; Wed, 22 Oct 2014 09:06:25 -0700 (PDT)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id C13C3B3766B7E; Wed, 22 Oct 2014 16:06:21 +0000 (GMT)
Received: from ( []) by (GMO) with ESMTP id s9MG68oJ014329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 12:06:23 -0400
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 12:06:23 -0400
From: "Makaraju, Maridi Raju (Raju)" <>
To: Sergio Garcia Murillo <>, "" <>
Thread-Topic: [rtcweb] SDP and ssrc-group,
Thread-Index: AQHP7ViUdeZEO6Q8ck+bZW3ftl2D4pw7JCgA///BDVCAAGQngIAA/6NQ
Date: Wed, 22 Oct 2014 16:06:22 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E5EC0CAUS70UWXCHMBA02z_"
MIME-Version: 1.0
Subject: Re: [rtcweb] SDP and ssrc-group,
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Oct 2014 16:06:29 -0000

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


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

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


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