Return-Path: 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 D62DE1A6FDD for ; Mon, 27 Oct 2014 10:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 QE6La84A5DWb for ; Mon, 27 Oct 2014 10:12:40 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5881A6F80 for ; Mon, 27 Oct 2014 10:10:50 -0700 (PDT) Received: from [130.209.247.112] (port=60320 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xinod-0003l5-Sj; Mon, 27 Oct 2014 17:10:48 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_1EBC4EB5-4902-496C-88C9-AC65E685503A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <544E781D.50305@gmail.com> Date: Mon, 27 Oct 2014 17:10:45 +0000 Message-Id: <17742E9C-CCDD-4EFE-A2C1-C84531A0523F@csperkins.org> References: <5446ACD8.1010004@gmail.com> <544E7586.4080703@gmail.com> <22D97583-2E07-417C-84CC-923FD83C008C@csperkins.org> <544E781D.50305@gmail.com> To: Sergio Garcia Murillo X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7q-TFMbA5qDUVoDcpQ_OMqLPiEI Cc: "" Subject: Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE X-BeenThere: rtcweb@ietf.org 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: Mon, 27 Oct 2014 17:12:43 -0000 --Apple-Mail=_1EBC4EB5-4902-496C-88C9-AC65E685503A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 27 Oct 2014, at 16:51, Sergio Garcia Murillo = wrote: > On 27/10/2014 17:45, Colin Perkins wrote: >> On 27 Oct 2014, at 16:40, Sergio Garcia Murillo = wrote: >>> On 27/10/2014 17:36, Colin Perkins wrote: >>>> On 21 Oct 2014, at 19:58, Sergio Garcia Murillo = wrote: >>>>> Not sure if it is done on pourpose, but according to the RTP usage = draft, it may seem that full RFC 4588 is mandated at the recevier side: >>>>>=20 >>>>> Receivers are REQUIRED to implement support for RTP = retransmission >>>>> packets [RFC4588]. >>>>>=20 >>>>> That would include both modes, session and ssrc multiplexing. = Given the extensive usage of bundle and current implementations, session = multiplexing support doesn't make much sense. >>>>>=20 >>>>> Should we drop it, and state that only ssrc-multiplexing shall be = supported at the receiving end? >>>>=20 >>>> I don=92t see any advantage to doing so, given that support for = non-BUNDLE sessions is REQUIRED. You need to implement the signalling = needed for session-multiplexing of retransmission packet anyway, so = disallowing it buys you nothing. >>>=20 >>> You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, = what I don't see is how to do session multiplexing with BUNDLE sessions.=20= >>=20 >> You can=92t do session multiplexing for BUNDLE sessions; by = definition they use SSRC multiplexing. You could do non-BUNDLE sessions, = with retransmission sent on a separate RTP session though. >>=20 > So, you are saying exactly the same than me. SSRC multiplexing = supports both BUNDLE and NON-BUNDLE. So, why require support for session = multiplexing at all? As a developer, I don't see why I would have to = implement something that would be rarely used and provide no extra = benefit. Non-BUNDLE is session multiplexing. It uses a separate RTP session for = the retransmissions.=20 > Also, the original discussion came from the ORTC list, as ORTC API = only supports ssrc-multiplexing RTX. If we require both modes on WebRTC = "just for fun", then ORTC API will not be able to comply with the RTP = usage draft. I=92m perhaps missing something, but it seems that the features needed = for session-multiplexed retransmission are required anyway (a=3Dgroup, = plus the ability to send non-BUNDLE media).=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_1EBC4EB5-4902-496C-88C9-AC65E685503A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On 27 = Oct 2014, at 16:51, Sergio Garcia Murillo <sergio.garcia.murillo@gmai= l.com> wrote:
=20 =20
On 27/10/2014 17:45, Colin Perkins wrote:
On 27 Oct 2014, at 16:40, Sergio Garcia Murillo <sergio.garcia.murillo@gmai= l.com> wrote:
On 27/10/2014 17:36, Colin Perkins wrote:
On 21 Oct 2014, at 19:58, Sergio Garcia Murillo <sergio.garcia.murillo@gmai= l.com> wrote:
Not sure = if it is done on pourpose, but according to the RTP usage draft, it may seem that full RFC 4588 is mandated at the recevier side:

    Receivers are =
REQUIRED to implement support for RTP retransmission
    packets [RFC4588].

That would include both modes, session and ssrc multiplexing. Given the extensive usage of bundle and current implementations, session multiplexing support doesn't make much sense.

Should we drop it, and state that only ssrc-multiplexing shall be supported at the receiving end?

I don=92t see any advantage to doing so, given that support for non-BUNDLE sessions is REQUIRED. You need to implement the signalling needed for session-multiplexing of retransmission packet anyway, so disallowing it buys you nothing.

You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I don't see is how to do session multiplexing with BUNDLE sessions.

You can=92t do session multiplexing for BUNDLE sessions; by definition they use SSRC multiplexing. You could do non-BUNDLE sessions, with retransmission sent on a separate RTP session though.

So, you are saying exactly the same than me. SSRC multiplexing supports both BUNDLE and NON-BUNDLE. So, why require support for session multiplexing at all? As a developer, I don't see why I would have to implement something that would be rarely used and provide no extra benefit.

Non-BUNDLE = is session multiplexing. It uses a separate RTP session for the = retransmissions. 

Also, the original discussion came from the ORTC list, as ORTC API only supports ssrc-multiplexing RTX. If we require both modes on WebRTC "just for fun", then ORTC API will not be able to comply with the RTP usage draft.

I=92m = perhaps missing something, but it seems that the features needed for = session-multiplexed retransmission are required anyway (a=3Dgroup, plus = the ability to send non-BUNDLE media). 

-- 
Colin Perkins

<= /div>


= --Apple-Mail=_1EBC4EB5-4902-496C-88C9-AC65E685503A--