IETF Logo Mail Archive

Re: [rtcweb] SDP and ssrc-group,

Justin Uberti <juberti@google.com> Wed, 29 October 2014 04:23 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543E21A6F5A for <rtcweb@ietfa.amsl.com>; Tue, 28 Oct 2014 21:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.012
X-Spam-Level: *
X-Spam-Status: No, score=1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x92ZPh7YB09q for <rtcweb@ietfa.amsl.com>; Tue, 28 Oct 2014 21:23:55 -0700 (PDT)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD331A0111 for <rtcweb@ietf.org>; Tue, 28 Oct 2014 21:23:55 -0700 (PDT)
Received: by mail-ob0-f171.google.com with SMTP id wp18so1767273obc.2 for <rtcweb@ietf.org>; Tue, 28 Oct 2014 21:23:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yxyU+VmvZjPo9bm+luWx1EmcdsCq+aihN86SdwYv4q0=; b=kc+GgMMCNXYAeNGhbReWNxU96Tszq7ryhL482hH+ivpmimM/2CErXvqOPhRGOOFDSG J69Gmvcy30o1QdJdDPMb4ABhcVZA1oZFfx95p1MmOFptTk5ySJRmMAowneUeb1RB6pWv CmNR0Ynu9AFfmUguAcTxV6RGb3z8QhtRkvcNULl7NKRqYANZkL348w0QA4ijT1kG7z6b XOtReC9vsFCiTh12jFK3TUaPVte97J1gWCruftdyivaqKVA7jESE6bWiN0RgM6qYFHrH dkdPx14XT24pQ5h7ekAI2Ysm0lRvY1sjkuvBt6TU82h90WlhTXakJdRQTavwz/GJCf/Y iVng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yxyU+VmvZjPo9bm+luWx1EmcdsCq+aihN86SdwYv4q0=; b=a6Z92uez4yGEo/ynSDKAm0+p97P1bKrN8JzJjZ5ZBXNuhU7O8YZoZHP+RVkTlKPDti 0CdyldT910bc1bMPKQgYudGPx+C8ob7v3vO7tPNZZ64jNQ3kVqHVyrNFNDGd5aJSu6WE CZTcJbuHyUiddc0uliADUtum+Po8WRZQ1Ujzwc+c/q3DgbWzpsEUxIQOK89AOFT5kl9I 0tHSppsJANatdiL5tm2Gwi9DsGVMQyI8DkFLVJn4pt/KzhcKpuR8tw4hv5Y+DsqiQgT4 XIvvWF04Q+yihN9QYyWyU8YOSl4DDxyoeUC6KO6pfYFdS0+BzaQZQpcHSAGXuJqUjcZ5 aQlQ==
X-Gm-Message-State: ALoCoQmvey3ubwwn4tfA9KccLXDRxhOoLg2qAhwunEdqcMPFBsINDF715VdUBe8FJQmMKi/GT2KF
X-Received: by 10.182.130.232 with SMTP id oh8mr79603obb.49.1414556634701; Tue, 28 Oct 2014 21:23:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.248.170 with HTTP; Tue, 28 Oct 2014 21:23:34 -0700 (PDT)
In-Reply-To: <E1FE4C082A89A246A11D7F32A95A17828E5EE2D3@US70UWXCHMBA02.zam.alcatel-lucent.com>
References: <CALiegfmH8rRyEDbJjQ=kzMv0nGC=S9gNsE7roE=kqJyVcfgy8g@mail.gmail.com> <CAJrXDUHekuQCLeCYzsnm8AuTUgiVppQHUqR7MKdQ9Q=eFFAy0w@mail.gmail.com> <CALiegfm_B5KfD5SBPzsH4YYuzD2OXdu47TtatPVmd6ihrMCh1A@mail.gmail.com> <CAJrXDUF-AXcDuQmYhH91vbgPAxLkYkB==GY9opoRk7zrEP8A7A@mail.gmail.com> <CALiegfmxnzZ6_3rKX0paNhHas6Emvu1Mekgb9caj9NLVSf_u+g@mail.gmail.com> <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> <54480864.4050106@gmail.com> <5448583B.5090109@mozilla.com> <E1FE4C082A89A246A11D7F32A95A17828E5EE05D@US70UWXCHMBA02.zam.alcatel-lucent.com> <544936E5.2040909@mozilla.com> <E1FE4C082A89A246A11D7F32A95A17828E5EE2D3@US70UWXCHMBA02.zam.alcatel-lucent.com>
From: Justin Uberti <juberti@google.com>
Date: Tue, 28 Oct 2014 21:23:34 -0700
Message-ID: <CAOJ7v-0Z+eGPNM0JVTWq1Q90eU4pc49+O4rEOkzwTJmBiyoz0Q@mail.gmail.com>
To: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="089e013a03c6ba0660050688216d"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kyu8mQZMgNA2JIADCJaiDlaw2IM
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] SDP and ssrc-group,
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Oct 2014 04:23:57 -0000

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)


On Thu, Oct 23, 2014 at 12:29 PM, Makaraju, Maridi Raju (Raju) <
Raju.Makaraju@alcatel-lucent.com> 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] https://www.ietf.org/mail-archive/web/rtcweb/current/msg12353.html
> [Raju] Thanks and appreciate the reference.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

v2.23.0 | Report a Bug | By Email