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

"Paul Giralt (pgiralt)" <> Sat, 23 November 2013 00:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4C2DE1AE228 for <>; Fri, 22 Nov 2013 16:20:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.426
X-Spam-Status: No, score=-14.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sbjztlD15qTP for <>; Fri, 22 Nov 2013 16:20:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B68B91AE206 for <>; Fri, 22 Nov 2013 16:20:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1818; q=dns/txt; s=iport; t=1385166034; x=1386375634; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jxu3DthlFS+HtxQ4u7+Nks1YuGRl0IWKg3/8Dg2RMQE=; b=eyUPVvdI/x+3b0n/6ptIa6jWWI0Oh9t1tkhKOuu/Kob0eAAMDEpJLJx2 R+NoVtwk5EWEBOW7loaY231oo442o3kXLX6icFoJ6uUMZGFhKIZTTmWA1 0tdjHdumahuOscQTi0ceWwH0JZpWoEUzHlU8hCapYwuHJwQu1yqUNFjo5 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgwFAIP0j1KtJXG9/2dsb2JhbABZgweBC7wUgR8WdIIlAQEBAwF5BQsCAQgYLiERJQIEDgWHbwMJBrhuDYgnF4x4gVwzB4MggRMDlimBa4xahTiDKIFoBQI7
X-IronPort-AV: E=Sophos;i="4.93,755,1378857600"; d="scan'208";a="286991674"
Received: from ([]) by with ESMTP; 23 Nov 2013 00:20:19 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rAN0KIFL007830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Nov 2013 00:20:18 GMT
Received: from ([]) by ([fe80::200:5efe:]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 18:20:18 -0600
From: "Paul Giralt (pgiralt)" <>
To: Martin Thomson <>
Thread-Topic: [rtcweb] Offer/answer for heterogeneous encode/decode
Thread-Index: AQHO58/XQlURsOaoj0uaxvupayfvnZoyTmqAgAAGSwCAAAPRAA==
Date: Sat, 23 Nov 2013 00:20:18 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 00:20:42 -0000

On Nov 22, 2013, at 7:06 PM, Martin Thomson <> wrote:

> On 22 November 2013 15:44, Paul Giralt (pgiralt) <> wrote:
>> While you’re right that it would work for this scenario, my point was really
>> that Offer/Answer is not really asymmetric as implied earlier. Take for
>> example the hypothetical case where you are only able to decode VP8 but only
>> able to encode H.264. If I offer VP8 as my only codec (because it’s the only
>> thing I’m able to decode therefore I never want anyone to send me anything
>> other than VP8) I cannot send H.264 in the offer because that implies I’m
>> able to decode it. The other side then wants to say it can only receive
>> H.264 so it would have to send back an answer with only H.264. I guess
>> there’s nothing really inherently stopping you from doing this because as
>> far as I can tell, 3264 only says the answer has to be a subset of the offer
>> for multicast streams, however how would the answering side know that the
>> offering side is even capable to receiving H.264? Perhaps Offer/Answer can
>> technically be asymmetric, but it doesn’t seem practical to use it this way
>> because you cannot really indicate your send and receive capabilities
>> independent of each other.
> Judicious application of a=sendonly or a=recvonly avoids this issue.
> If you want to send H.264, try a=sendonly on a line with H.264.  If
> you want to receive VP8, try a=recvonly on a line with VP8.

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.