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

"Paul Giralt (pgiralt)" <> Fri, 22 November 2013 23:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2B83B1AE117 for <>; Fri, 22 Nov 2013 15:44:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.025
X-Spam-Status: No, score=-15.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 UHBmPjuJfMMr for <>; Fri, 22 Nov 2013 15:44:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7B3781AE14B for <>; Fri, 22 Nov 2013 15:44:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9479; q=dns/txt; s=iport; t=1385163849; x=1386373449; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TB8papLWCshZ36n0RxDHDljP0tmivyThznsS5Hcga4Y=; b=NJa+e6WjXjvWotOSNh8SxFxeNMkGB4NYn0YG7U1y0Ik1NSbpkN9waslQ 8QY2pHe8ChsY2Pn+gmbc5bdnthMKQTkweEQqvySDe7wsJQkQdstc/ofZl ctBzxiQsdJLEqLTeYvn8NJMunLxemEXlZY0bWcgV3BrknqyGagvtUgV2P s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.93,755,1378857600"; d="scan'208,217"; a="286973602"
Received: from ([]) by with ESMTP; 22 Nov 2013 23:44:09 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rAMNi88f007708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 23:44:08 GMT
Received: from ([]) by ([fe80::200:5efe:]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 17:44:08 -0600
From: "Paul Giralt (pgiralt)" <>
To: Justin Uberti <>
Thread-Topic: Offer/answer for heterogeneous encode/decode
Thread-Index: AQHO58/XQlURsOaoj0uaxvupayfvnZoyTmqA
Date: Fri, 22 Nov 2013 23:44:07 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_59A91D843D2947C48688CB60844B15D3ciscocom_"
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: Fri, 22 Nov 2013 23:44:19 -0000

On Nov 22, 2013, at 5:11 PM, Justin Uberti <<>> wrote:

On Fri, Nov 22, 2013 at 11:57 AM, Paul Giralt <<>> 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".

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.