[MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast

Bo Burman <bo.burman@ericsson.com> Mon, 13 March 2017 09:56 UTC

Return-Path: <bo.burman@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D4312954B; Mon, 13 Mar 2017 02:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com
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 uicZnbLxQqIp; Mon, 13 Mar 2017 02:56:42 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226D5129400; Mon, 13 Mar 2017 02:56:40 -0700 (PDT)
X-AuditID: c1b4fb30-3623498000006a1c-93-58c66cd7547f
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 53.05.27164.7DC66C85; Mon, 13 Mar 2017 10:56:39 +0100 (CET)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 13 Mar 2017 10:56:38 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=e16f+CC6yx7f1hd1J/FtBqGya6GprIAeMxfgbWO3nxI=; b=LqdwLstrOnYPHKSjg0ZXTseRTEtlBTYsaITkVdQsWOL5o7WHl0yLMSjcqKTr2XI0nSwijFjmnM12rZp9qnzNCdh0GthLsVCJceRH1B821xXOjVnpJgN+PjyLw9tTXbSyFzYLsHKkB4GqAjzk3KO48dQAGKdrrjZ7BgJnT/mzotc=
Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2579.eurprd07.prod.outlook.com (10.173.92.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Mon, 13 Mar 2017 09:56:37 +0000
Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.0961.021; Mon, 13 Mar 2017 09:56:37 +0000
From: Bo Burman <bo.burman@ericsson.com>
To: "mmusic (mmusic@ietf.org)" <mmusic@ietf.org>, "Taylor Brandstetter (deadbeef@google.com)" <deadbeef@google.com>
Thread-Topic: [rtcweb] How to signal RTX SSRCs with simulcast
Thread-Index: AQHSmSRXaXEak/rxUUuXLqrZPXzB4qGOeTSAgAADuwCAADM6gIAAAMcAgAAFxYCAA7fx4A==
Date: Mon, 13 Mar 2017 09:56:36 +0000
Message-ID: <AM5PR0701MB2577FD1D3E43697C4672F80C8D250@AM5PR0701MB2577.eurprd07.prod.outlook.com>
References: <CALiegfkM+Gh5tnu_LU+Lo4FM_OVy+TixyBt2zBtoREucHHAsCg@mail.gmail.com> <3A98F0E8-772E-40E3-A872-5414AC8FDF35@iii.ca> <CALiegfm0+GkfTvUk0Kfj2SLf+zcw-k6b-xnqXd4omnVy7mPTEg@mail.gmail.com> <12EA18B8-39F0-491F-92B6-D41F3D640209@iii.ca> <CALiegfndNRoBH-1TYvLhC2TZsWApaLLZ0WBjh3HzL4pYJtCmGQ@mail.gmail.com> <CAK35n0ZuGu+FxYsdDGkX4aomeTC68XvBd0MniKS7NzdAeuEACQ@mail.gmail.com>
In-Reply-To: <CAK35n0ZuGu+FxYsdDGkX4aomeTC68XvBd0MniKS7NzdAeuEACQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [192.176.1.84]
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2579; 7:kWCp0l3S0lWRmQp5UqYKMpO8ifoZjfPlyWe2PQTO9hoOCM2D3xbzhApTKb+AAzRxUaRTlo/oBeDNzwr8w84qq8BT2UhORdlKYgVeV/aby84zP3/95Pyvonr3Yt2Y4l2ylqcoBpEo122EKbTR9vVb222v39fqZt063+coGb4YprrexJMfdBqHY0QN6rpmB1Wc7j+7CPUTLeYlCA1hlwM16IBiJ7Cq1dId0GX+UH4jd4GA1hgOgxh0FNoMYEBpeD5QHKO4/0qUHDYx9k9/4MvDXWbOVND8/grHMTRp3nJbCyNicqb0MWx6JXWf0Xp1N6jlbeT0U+PePFMwSShnR4Fp/g==
x-ms-office365-filtering-correlation-id: c3613b36-61b3-4f19-5d1c-08d469f73d4d
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2579;
x-microsoft-antispam-prvs: <AM5PR0701MB2579FC59325AE65E911148C18D250@AM5PR0701MB2579.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(6072148); SRVR:AM5PR0701MB2579; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2579;
x-forefront-prvs: 0245702D7B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(51444003)(377454003)(377424004)(24454002)(6116002)(790700001)(66066001)(3660700001)(3846002)(122556002)(3280700002)(102836003)(561944003)(33656002)(99936001)(189998001)(54356999)(5660300001)(50986999)(76176999)(2900100001)(9686003)(606005)(99286003)(6306002)(54896002)(236005)(106116001)(6436002)(25786008)(93886004)(2906002)(53936002)(2950100002)(7696004)(77096006)(6506006)(229853002)(74316002)(81166006)(8936002)(19609705001)(55016002)(4326008)(8676002)(86362001)(38730400002)(53546006)(7906003)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2579; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/mixed; boundary="_004_AM5PR0701MB2577FD1D3E43697C4672F80C8D250AM5PR0701MB2577_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 09:56:37.0039 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2579
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA2WSa0iTURjHOe9lvpqL09J8sIJchZaZNSxGaRT1wbCL9iFHFG3pmxNts81J hYRiZrkumpk6NUUHWprKMDbDRK20qZCmzS7elXRRlKFoKNV83xVB337n//zP/3nOhSFFeoE3 E6tKZDUqRbxY4EYVyMwRAf3xbbJtVsN6aW/lKC3Nrq0hpJOGKUqaWzFO7aVCS026UKPxBxFO nHALjmbjY5NYTeAeuZuyN/O1ICGtgrhw+3GnSwpKLSEykSsDOAie5VbRmciNEeEaBNW5zS78 4iWC8uIhcmlB4ZskWBusAr6SR0Bx+Qjx12YwztNLYQLsByWWQbTEHlgHH2yzXDCJSxHcaOvm CitxMJj7RkjeFAK/miwUz8chp2GGYwpvhJv55ZxHiOVgMX90tk4nYeZNNze6K44Ac/ZXLhTh VTDXUc3pJPaC9xN/jucBoz2dAp49wT7+k5sIYT2Cb/dtTtM6+KRP4ToAvkVCzpSe5guHob26 meL5KMxlpDuYcbAaCvPW8vIuuJbdTvN7HxAw19Pu9K+BMku6M7SeBtPDRef5vWGw77qT18DU wFM6C/kZ/pmc51h4dGUaGbgrWAHWggmK19WQYesUGBxzkHgT1D4J5GUfuKsfdeHZD9KLil3+ 1wPg+au2v/pVc5ojZul5KhF8mbURfGYoVDWq/t1bioQPkaeW1Z45FyORbGU1sVFarVq1VcUm mpDjW7bUL2yzIPvkvlaEGSR2F9YZXshEtCJJe/FcK9rgyBmrq+pG3pRKrWLFHsKGqDaZSBit uHiJ1ahPa3TxrLYVrWYosZdw54PhSBGOUSSycSybwGr+VAnG1TsFLS8Jb5ruar93bExubPhs 9y8MSlayA7S/tMN9MeZ8ztAw3ZXs23/5Sj+RzwaX78+6HmIM2HHkq5y+0zjm/m78eZE9JGzS 15R8aO5s2e6hjDidxGf8YGWQjF1nWGZbCBs+UNfZmNqS+l2pO+nZN6/s2GJhTJGnorzskrct 2YGSRTGlVSq2byY1WsVvgN+5Mp4DAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/KYinkadvOI_ef_e5IyKxuZquODc>
Cc: "draft-ietf-mmusic-rid@ietf.org" <draft-ietf-mmusic-rid@ietf.org>, "draft-ietf-mmusic-sdp-simulcast@ietf.org" <draft-ietf-mmusic-sdp-simulcast@ietf.org>
Subject: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Mar 2017 09:56:44 -0000

All,

This is forwarding a discussion that started in RTCWEB that mainly applies to -mmusic-rid and -mmusic-sdp-simulcast. I suggest we continue the detailed discussion here in MMUSIC.

As the forwarded mail says, it is still somewhat unclear what question that needs an answer, but it is clearly related to joint use of “a=rid”, “a=simulcast”, and use of retransmission (“rtx” format from RFC 4588). I think such usage may be slightly under-specified in one or both of the above drafts.

I think what Taylor suggests below is a very good start and may actually provide the solution we want (and should then document better).

I however note that:

·         RFC 4588 (section 4) says that RTP Header Extensions (such as RtpStreamId, used for “a=rid”) SHOULD be repeated by the retransmitted packet:
   “If the original RTP header carried an RTP header extension, the
   retransmission packet SHOULD carry the same header extension.  This
   header extension MUST be placed right after the fixed RTP header, as
   specified in RTP [3].  In this case, the retransmission payload
   header MUST be placed after the header extension.”

·         It is not self-evident that the retransmission redundancy RTP stream (RFC 7656) should be assigned the same RtpStreamId as the RTP stream it protects, especially since that would prevent assigning a separate RtpStreamId to the redundancy RTP stream itself (if that is ever needed)

·         -avtext-rid already provides a way to deal with this by defining RepairedRtpStreamId, but -mmusic-rid currently does not in any way detail its usage

I believe we need to decide on and document:

·         Whether to use RtpStreamId or RepairedRtpStreamId in the rtx redundancy RTP stream to indicate what RtpStreamId the original RTP stream has

·         If using the same RtpStreamId in the rtx redundancy RTP stream as in the original RTP stream (basically Taylor’s proposal):

o   That it is aligned with the RFC 4588 recommendation to copy original RTP HE (verbatim) into retransmitted packet

o   That “a=rid” specifies both original format and rtx format for the “pt=” parameter (as Taylor suggests below)

o   That this clearly indicates in SDP which “a=rid” uses retransmission (by pointing also to a rtx PT)

o   That if the rtx redundancy RTP stream itself needs an RtpStreamId, RepairedRtpStreamId is instead used to relate to the original RTP stream; I note that there’s a risk that an implementation that does not know of RepairedRtpStreamId will then not find the relation between original and rtx RTP stream

·         If always using RepairedRtpStreamId in the rtx redundancy RTP stream to relate to the original RTP stream:

o   That it is an (intentional) deviation from the RFC 4588 recommendation to repeat RTP Header Extension verbatim, but instead uses a format that “points” to what the original HE was

o   That “a=rid” specifies only the original format in “pt=” (because the rtx stream does not use that RtpStreamId, but uses RepairedRtpStreamId instead)

o   That this does not indicate in SDP which “a=rid” uses retransmission, but that the relation can only be found in the rtx redundancy RTP stream through RepairedRtpStreamId (HE and RTCP SR)

o   That the rtx redundancy RTP stream may, but need not, have an RtpStreamId of its own; in this case, there should be no risk that an implementation does not know of RepairedRtpStreamId or that it is used to relate to the original RTP stream RtpStreamId

·         In both cases above, RTCP SR with SDES RtpStreamId and/or RepairedRtpStreamId for the rtx redundancy RTP stream can be used by the RTP receiver to learn which SSRC the retransmitted stream has, even before receiving the first retransmitted RTP packet

I’m personally slightly inclined to suggest always using RepairedRtpStreamId in the rtx redundancy RTP stream to relate it to the original RTP stream (second “if” bullet above), mainly to avoid having to change interpretation of RtpStreamId based on the optional presence of RepairedRtpStreamId. I’m of course open to arguments.

I also propose that this relation between “a=rid” and retransmission is documented in -mmusic-rid rather than in -mmusic-sdp-simulcast, since I find nothing in this that is specific to simulcast.

/Bo
(as individual)

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Taylor Brandstetter
Sent: den 11 mars 2017 00:18
To: Iñaki Baz Castillo <ibc@aliax.net>
Cc: RTCWeb IETF <rtcweb@ietf.org>rg>; draft-ietf-mmusic-sdp-simulcast@ietf.org
Subject: Re: [rtcweb] How to signal RTX SSRCs with simulcast

What question are we still trying to answer? "How do we know that RTX is active"? I think Iñaki already gave the right answer earlier: if the endpoints negotiate an RTX "media format" ("a=rtpmap:96 rtx/90000"), each endpoint should be prepared to receive RTX packets for any encoding.

And if the "rid" line explicitly specifies what payload types are allowed to be used with that RID, it just needs to include the RTX payload type to allow RTX to be used. Like so:

a=rtpmap:96 VP8/90000
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rid:foo send pt=96,97

But JSEP doesn't say "pt=" should be used, so I don't think this is even a concern.


On Fri, Mar 10, 2017 at 2:56 PM, Iñaki Baz Castillo <ibc@aliax.net<mailto:ibc@aliax.net>> wrote:
2017-03-10 23:54 GMT+01:00 Cullen Jennings <fluffy@iii.ca<mailto:fluffy@iii.ca>>:
>> If no simulcast, those two video streams are in different m=video sections, right?

> yes

I think that your example does not "work" well since simulcast is
achieved within a single m=video section.


--
Iñaki Baz Castillo
<ibc@aliax.net<mailto:ibc@aliax.net>>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb