Re: [rtcweb] SDP and ssrc-group,

Christer Holmberg <> Wed, 29 October 2014 06:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 444591A0861 for <>; Tue, 28 Oct 2014 23:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RYPgDIDlil1t for <>; Tue, 28 Oct 2014 23:54:37 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AEFD61A1B44 for <>; Tue, 28 Oct 2014 23:54:36 -0700 (PDT)
X-AuditID: c1b4fb3a-f79596d000001123-30-54508f29df12
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id D7.6D.04387.92F80545; Wed, 29 Oct 2014 07:54:34 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 07:54:33 +0100
From: Christer Holmberg <>
To: Martin Thomson <>, Justin Uberti <>
Thread-Topic: [rtcweb] SDP and ssrc-group,
Date: Wed, 29 Oct 2014 06:54:32 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4D2633ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGfG3RlerPyDEoO+msMXWqUIW1878Y7RY +6+d3YHZY+esu+weCzaVeixZ8pMpgDmKyyYlNSezLLVI3y6BK2Pv1rfsBR9aGSuWrJzM2MC4 pImxi5GTQ0LAROL93/XMELaYxIV769m6GLk4hASOMErcWbELylnCKHHqyiyWLkYODjYBC4nu f9ogDSICwRK3jt4Fa2YWUJe4s/gcO4gtLKApsebkQyaIGi2JZf96GUHmiAg0MUrc37aPDSTB IqAq8ez/O7AGXgFfiSffWllAbCGBTWwSLzdHgeziFAiUWNhfBRJmBDru+6k1TBC7xCVuPZnP BHG0gMSSPeehHhCVePn4HytIq4SAosTyfjmI8nyJ5113oTYJSpyc+YRlAqPoLCSTZiEpm4Wk bBbQJGagb9bv0ocoUZSY0v2QHcLWkGidM5cdWXwBI/sqRtHi1OLi3HQjI73Uoszk4uL8PL28 1JJNjMD4O7jlt9UOxoPPHQ8xCnAwKvHwbmDzDxFiTSwrrsw9xCjNwaIkzrvw3LxgIYH0xJLU 7NTUgtSi+KLSnNTiQ4xMHJxSDYwccapH8hYuOWc82S/g3+87Hb3WVXEPf7fEvK2o54/J2pFw d+uvYqHDO09kKqgUdUvHljyr8Vle06A17W1/bdiK+DMJyX8OPs48L53xI/TL/OUMOzYqBU3l uhnm/XfXiigpK4fMyAt5Hvav91rv4vbpcl/qu/D44a9/9HZ9t5+yLjH1Z7yF5jclluKMREMt 5qLiRABTkCAQoAIAAA==
Cc: "" <>
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, 29 Oct 2014 06:54:39 -0000


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

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.



On Oct 28, 2014 9:24 PM, "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)

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

On Thu, Oct 23, 2014 at 12:29 PM, Makaraju, Maridi Raju (Raju) <<>> wrote:
> 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]
[Raju] Thanks and appreciate the reference.

rtcweb mailing list<>

rtcweb mailing list<>