Re: [rtcweb] A proposal for FEC

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 19 May 2014 16:01 UTC

Return-Path: <magnus.westerlund@ericsson.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 7DA471A0104 for <rtcweb@ietfa.amsl.com>; Mon, 19 May 2014 09:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
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 7wZumQEKNvLW for <rtcweb@ietfa.amsl.com>; Mon, 19 May 2014 09:01:33 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72BB61A0116 for <rtcweb@ietf.org>; Mon, 19 May 2014 09:01:32 -0700 (PDT)
X-AuditID: c1b4fb3a-f79746d000006fe2-ba-537a2ada7607
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 46.A9.28642.ADA2A735; Mon, 19 May 2014 18:01:30 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.174.1; Mon, 19 May 2014 18:01:29 +0200
Message-ID: <537A2AD7.1090209@ericsson.com>
Date: Mon, 19 May 2014 12:01:27 -0400
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Bernard Aboba <bernard.aboba@gmail.com>
References: <CAOJ7v-1jZ=TPpc=4w01wh7Sk_Y22Q2s82M=tdBdv72k6bwo8Ow@mail.gmail.com> <537A2461.2020300@ericsson.com> <CC1C57C1-FBF5-401B-9525-4B99EE098A59@gmail.com>
In-Reply-To: <CC1C57C1-FBF5-401B-9525-4B99EE098A59@gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM+Jvje4trapgg/vXdS027PvPbLF1qpDF 2n/t7A7MHjtn3WX3WLCp1GPJkp9MAcxRXDYpqTmZZalF+nYJXBl9l2YyFizgr3g7W7yBcRpP FyMnh4SAicSLzdvZIGwxiQv31gPZXBxCAkcZJfq3vmSEcJYzSqzs/MAMUsUroC2x6McLRhCb RUBVYtneC2BxNgELiZs/GsEmiQoES2x4+Jcdol5Q4uTMJywgtghQb9+3fUwgNrOAt8SnRQ+A ajg4hAU0JDpv20PsWsgo8eLjfrAaTgFbicUfrzOD1EgIiEv0NAZBtOpJTLnawghhy0s0b50N doIQ0PiGpg7WCYxCs5BsnoWkZRaSlgWMzKsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYxAoP6 4JbfVjsYDz53PMQowMGoxMO7ILUyWIg1say4MvcQozQHi5I4r49MVbCQQHpiSWp2ampBalF8 UWlOavEhRiYOTqkGRin2nqYKrTb+lrO8DbsSU2pPO15otGuPral69IgviinKvSj3hWzVvzct ig6mU75UW0gEN3gJPPu8cN57n6VmOn6+ii5hhnfirjO1/j11xqnk5QJG95VPf2xs527pXLxB 4faS31X2rh+k4zP8CkxMO1TtPT+33nhVr/r8PF9w3ZWlua/aTz5TYinOSDTUYi4qTgQAMn4R OksCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DQOqv01B5KnfeRLx4-Wj4nYAHyU
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] A proposal for FEC
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: Mon, 19 May 2014 16:01:37 -0000

On 2014-05-19 11:58, Bernard Aboba wrote:
>>
>> On May 19, 2014, at 11:33 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
>>
>> I think adding ULPFEC in WebRTC is reasonable, however despite what RFC
>> 5956 says, we do have a spec issue with the following part of RFC 5109
>> that will be required to be overridden:
>>
>> Section 7.2:
>>
>>   Synchronization Source (SSRC): The SSRC value SHALL be the same as
>>   the SSRC value of the media stream it protects.
>>
>> Section 14.1:
>>
>>   The SSRC of the FEC stream MUST
>>   be set to that of the protected payload stream.
>>
>>   So the FEC
>>   stream and the payload stream SHOULD be sent through two separate RTP
>>   session, and multiplexing them by payload type into one single RTP
>>   session SHOULD be avoided.  In addition, the FEC and the payload MUST
>>   NOT be multiplexed by SSRC into one single RTP session since they
>>   always have the same SSRC.
>>
>>> From my perspective this override should be done in a separate document
>> so that also others can use it and not being RTCWEB specific.
> 
> The following draft accomplishes this, no?
> http://tools.ietf.org/html/draft-lennox-payload-ulp-ssrc-mux
> 

Yes, but it needs some updates and polishing before ready for
publication. Also, it has not been adopted yet in any WG. But, I think
adopting it and getting it moved forward in an expedited fashion would
be the right way forward.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------