Re: [rtcweb] Offer/answer for heterogeneous encode/decode

Christer Holmberg <> Sat, 23 November 2013 14:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1D7171ADEB5 for <>; Sat, 23 Nov 2013 06:09:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pKxggems44o9 for <>; Sat, 23 Nov 2013 06:09:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BC9B11ADE88 for <>; Sat, 23 Nov 2013 06:09:25 -0800 (PST)
X-AuditID: c1b4fb30-b7f228e000003e6c-ab-5290b70d2f68
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 30.33.15980.D07B0925; Sat, 23 Nov 2013 15:09:17 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Sat, 23 Nov 2013 15:09:16 +0100
From: Christer Holmberg <>
To: Martin Thomson <>, "Paul Giralt (pgiralt)" <>
Thread-Topic: [rtcweb] Offer/answer for heterogeneous encode/decode
Thread-Index: AQHO59zCEI0MVwit1k+uXBoi6v2abpox30IAgAAD1ACAAAwTgIAA5cSigAAGiS0=
Date: Sat, 23 Nov 2013 14:09:15 +0000
Message-ID: <>
References: <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C552FCEESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+JvrS7v9glBBkt6BSyunfnHaHGz4TGj xdp/7ewOzB5Tfm9k9dg56y67x5IlP5kCmKO4bFJSczLLUov07RK4MlY+uMJesNShYta2h2wN jBtNuhg5OSQETCQONL1lhrDFJC7cW88GYgsJHGKUONzn08XIBWQvZpT437aHpYuRg4NNwEKi +582SI2IQIzE0gO7mEBsZgF1iTuLz7GD2MICThLTWr8wQ9Q4Syz7vIwFwvaTmNk5hR1kDIuA qsStfcUgYV4BX4l3hy4wQqw6xCSx+fctsHpOgUCJFzu3gd3DCHTb91NroHaJS9x6Mp8J4mYB iSV7zkPdLyrx8vE/VpD5EgJKEtO2pkGU50v0npvNCLFLUOLkzCcsExhFZyGZNAtJ2SwkZRBx PYkbU6ewQdjaEssWvmaGsHUlZvw7BFVjLXFj404mZDULGDlWMbLnJmbmpJebb2IExt7BLb8N djBuui92iFGag0VJnPfDW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYysn/8J/I64d6ZD YLOSecfNA5x+352+WIVIfrBdtt7HYnZz0Bvdr027Z36d9e50RmH8h2NzX4v0qrv5GrGqnug5 zhH+VyPO6+I8tfZUjTu153dYbLpn+FPW6ovv5KlzxX6WBHee/HD2/UyFFVnGV7MN1gt4MthI pqtMWrbQ+DLHrP+MTL+Nt69XYinOSDTUYi4qTgQATEM7oIsCAAA=
Cc: "" <>
Subject: Re: [rtcweb] Offer/answer for heterogeneous encode/decode
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: Sat, 23 Nov 2013 14:09:29 -0000


Like some others, I think the must-decode-both-must-endcode-one alternative as such sounds interesting (whether it has any impact on the licence/IPR issues I'll leave to others to speak for).

However, I have big concerns over the proposal to indicate sendrecv for a codec even if an entity is only able to receive/decode it.

As Justin said, for the "base case" we could probably make it work, as we would know than an rtcweb endpoint must be able to send/encode one of the codecs.

But, what when we add more codecs? Assume Alice sends an offer with H264, VP8 and the new fancy codec X. Bob supports codec X, but he has no clue whether Alice can actually encode it. So, in addition to X Bob will also have to include, and reservce resources for,  H264 and VP8 in the answer - just in case. And, when Alice receives the answer, she can not send a new offer and remove H264 and VP8, because she doesn't know whether Bob can encode X. It will not be possible to negotiate down to a single common codec X - even if both Alice and Bob are able to both encode and decode X.

...and, a legacy answerer which supports X may include only X in the answer, which means Alice has to send a new Offer, without X, in case she can only decode it.

Also, in case there is a gateway/transcoder, even if both endpoints indicate support of the same codec(s), it may still have to insert a transcoder, just in case - as it doesn't know which codecs the endpoints are able to encode.

So, I would STRONLGY RECOMMEND AGAINST allowing to indicate sendrecv for decode-only codecs. I think it would backfire very soon.

Usage of unidirectional, sendonly/recvonly, m- line would of course solve this, and you might know that it is one option we are discussing in CLUE (for other reasons than MTI codec, though).

Another alternative is to perform some kind of capability exchange before the actual offer is sent. But, that would of course increase the number of messages etc.



From: rtcweb [] on behalf of Martin Thomson []
Sent: Saturday, 23 November 2013 3:03 AM
To: Paul Giralt (pgiralt)
Subject: Re: [rtcweb] Offer/answer for heterogeneous encode/decode

On 22 November 2013 16:20, Paul Giralt (pgiralt) <> wrote:
> I gave this as an example of a possible way to do it, but that means you need two separate m= lines - one for send and one for receive. Seems strange to do this for something that you really want to be a single bi-directional stream

The bidirectional thing in O/A is the strange way to do things.  Two
lines is pretty intuitive.
rtcweb mailing list