Re: [rtcweb] SDP and ssrc-group,

"Mo Zanaty (mzanaty)" <> Wed, 29 October 2014 05:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6102E1A014C for <>; Tue, 28 Oct 2014 22:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -11.51
X-Spam-Status: No, score=-11.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mBd9Zrk0HRUJ for <>; Tue, 28 Oct 2014 22:51:09 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D32AA1A016D for <>; Tue, 28 Oct 2014 22:51:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=10143; q=dns/txt; s=iport; t=1414561869; x=1415771469; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tjVWzlsmm8oeFyjuI1kVqTiKYAri7l4IGFSVkVGBmyE=; b=htYjPku3jx4GBIiTaTEhrbE5IAszgolHoLYjCtOT+jSU+PQkK13kdQPT Yz3xORB0g/f+CD+M4aRQQicb3R8mGOLJDzLrQbUkpHUUj8igIaPQY7wll y85qgCh4NYU+UOHQglYvWOXLz+a+UpfpovSQ3RGWDS9D8jbmn75yk0CoI U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.04,808,1406592000"; d="scan'208,217";a="367383340"
Received: from ([]) by with ESMTP; 29 Oct 2014 05:51:05 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s9T5p5Aj024535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 05:51:05 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 00:51:05 -0500
From: "Mo Zanaty (mzanaty)" <>
To: Martin Thomson <>, Justin Uberti <>
Thread-Topic: [rtcweb] SDP and ssrc-group,
Thread-Index: AQHP8zxUqi1i1wqR+EyDmy+Vgek/aA==
Date: Wed, 29 Oct 2014 05:51:05 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D075F3CB3D2D6mzanatyciscocom_"
MIME-Version: 1.0
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 05:51:11 -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.).


On 10/29/14, 1:22 AM, Martin Thomson <<>> 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" <<>> 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<>