Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE

Colin Perkins <> Mon, 27 October 2014 19:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A0C021A039D for <>; Mon, 27 Oct 2014 12:16:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zLZILALFMjuP for <>; Mon, 27 Oct 2014 12:16:45 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 7E2501A038E for <>; Mon, 27 Oct 2014 12:16:44 -0700 (PDT)
Received: from [] (port=34845 helo=[]) by with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1XipmT-0002eW-Rs; Mon, 27 Oct 2014 19:16:42 +0000
Content-Type: multipart/alternative; boundary="Apple-Mail=_F0FBFB17-07D7-484B-BB29-D25DBC347429"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Mon, 27 Oct 2014 19:16:38 +0000
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Sergio Garcia Murillo <>
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Cc: "<>" <>
Subject: Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE
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 19:16:48 -0000

On 27 Oct 2014, at 17:17, Sergio Garcia Murillo <> wrote:
> On 27/10/2014 18:10, Colin Perkins wrote:
>> 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:
>>>>>>>     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’t 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’t 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. 
> Maybe I am the missing something, if you don't use bundle to send the audio/video on same rtpsession, you can still send rtx+video on     same session. That's it non-bundle with ssrc-multiplexing. Are we referring to different things?

Sure, but that doesn’t alter the fact that the group decided that non-BUNDLE media needs to be supported. Sending retransmission on a separate RTP session is as needed for interoperability with legacy systems as sending audio and video on separate RTP sessions (and shouldn’t be hard to support, since it uses the same mechanisms).


Colin Perkins