[rtcweb] Offer/answer for heterogeneous encode/decode

Justin Uberti <juberti@google.com> Fri, 22 November 2013 22:11 UTC

Return-Path: <juberti@google.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 5EBB21AE06E for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 14:11:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, 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 qPiOj3jEB8rs for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 14:11:46 -0800 (PST)
Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E15091ADF50 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 14:11:45 -0800 (PST)
Received: by mail-ve0-f170.google.com with SMTP id oy12so1423528veb.1 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 14:11:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=EFHD1Vxf3wC/kJ9TmC9SD/xgBP/aKlQfowuDP2mJQIY=; b=DXxluRphqvnJzFm4G5PEyqAtYDstMoc5bdJsL42ComBHkt/yZNSycLyhJg1Laohz8l VuJBsdnW414vWzqoPPwt05LrcUJgrM6zX13Wte40PUzc6wrRDnAwHQPOqkS24ygQ7rB9 pTfltmrVeeAB5cO4VDK6EuitIA3rXIo1TYzw2rY8+wgYpAi8L9WE1K0FyGpjMYCJp7Qf YW+X3mt9J9YBk8k35RRxZdEVnMLLK8K/rTJvrctC71go5HBmJPSEexcwWVvvox9JZf6/ vBq/fiygYGYc/7F9UkaRg8POSIauwEIItPW1+H7n8AR51tqESnDYLhoIJb7F168w+4ck 5vkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=EFHD1Vxf3wC/kJ9TmC9SD/xgBP/aKlQfowuDP2mJQIY=; b=LuUL+dCJpPGkEkpmPHcoAaKfqJ1rlPiTAIdynoLEb6k0+f56EX/X2//zXwYmC1uBrj s19fqA0ZELH1jhi9KpD0SxMGZc5AuI6nS+u2WwnMgYNWIoZiS8mAqdPbMU7kIoiu+8x2 9f/RCjuJCTSlTg5g2upWEQfrHaP1cEXqE+5PsPHEpbAFXFiZEUMLr9c9WXO3jAMzXAt7 bQW1Z4NS2IcEHR0Rf+Be753iOuDmNbQPZN+U3NizCN74RwoGVFg5eKuxeHLG3Bv/dTha nmSLpVJKR8KL0Smg5G/QwlX35aaNu57jAGQuDTU/9TvCQcO1ssSBiaxoyQX6whLgfer2 Xmhw==
X-Gm-Message-State: ALoCoQlEEf2ziktp5cdNZLZq3MU8oHFSAIQvWVuWD6YMvwH3bWwKOh1/aBjmYFF00TYQbmvcyvj6L0QHIkGrBKFE9ENensB5TCNriklaSZLHrY2ujhmN1NDFG0760w3ivWSyipCFztyy98tkjevwfZ+IgxWdsXIO4JHujWpQSGLmZhP4Sd6eeVGSlNVE4ufy+Ym0Xvl/ahZP
X-Received: by 10.52.32.37 with SMTP id f5mr11065232vdi.17.1385158298455; Fri, 22 Nov 2013 14:11:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Fri, 22 Nov 2013 14:11:18 -0800 (PST)
From: Justin Uberti <juberti@google.com>
Date: Fri, 22 Nov 2013 14:11:18 -0800
Message-ID: <CAOJ7v-2NSo7_KgARkYMDO6bca7msARL83d9gN3570F6sHoCJ9g@mail.gmail.com>
To: Paul Giralt <pgiralt@cisco.com>
Content-Type: multipart/alternative; boundary=bcaec51d2552566a4204ebcb4c98
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: [rtcweb] Offer/answer for heterogeneous encode/decode
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: Fri, 22 Nov 2013 22:11:48 -0000

On Fri, Nov 22, 2013 at 11:57 AM, Paul Giralt <pgiralt@cisco.com> wrote:

> I may be missing something but I don't know that this is entirely correct.
> From 3264:
>
>    The list of media formats for each media stream conveys two pieces of
>    information, namely the set of formats (codecs and any parameters
>    associated with the codec, in the case of RTP) that the offerer is
>    capable of sending and/or receiving (depending on the direction
>    attributes), and, in the case of RTP, the RTP payload type numbers
>    used to identify those formats.
>
> To me, this means that a capability in an offer or answer (with a
> direction attribute of sendrecv) means that you are capable of both sending
> and receiving for that particular capability. I don't see a way where you
> can specify (within a single m= line) that you are capable of receiving on
> two of the specified payload types, but only capable of sending on one of
> the two. In other words, if an offer or answer specifies both H.264 and VP8
> with a sendrecv attribute, this implies that you are capable of both
> sending and receiving both.
>
> You could, of course, specify two separate m= lines where you specify both
> codecs as recvonly and the codec you support for sending as sendonly, but
> this is very complicated because now you have two separate m= lines for
> what really should be one bi-directional stream.
>
> Someone please correct me if I'm misunderstanding this.
>
>
The sender has full discretion of which codec to actually use. Assuming the
remote side has offered both codec A and codec B (indicating that they are
willing to receive either), the local side can choose to send either A or
B, and can switch at any time.

>From later on in the paragraph from 3264 that you quoted:

   If multiple formats are listed, it
   means that the offerer is capable of making use of any of those
   formats during the session.  In other words, the answerer MAY change
   formats in the middle of the session, making use of any of the
   formats listed, without sending a new offer.

and later:

   In all cases, the formats in the "m=" line MUST be listed in order of
   preference, with the first format listed being preferred.  In this
   case, preferred means that the recipient of the offer SHOULD use the
   format with the highest preference that is acceptable to it.

I certainly think that "is acceptable to it" covers "has an encoder for it".