New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 6 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2018
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Sign in to add a comment

Issue 4040: subsequent answer with a codec not in the offer succeeds

Reported by, Nov 25 2014

Issue description

What steps will reproduce the problem?
Similar to to #4037:
1. enable VP9 support
2. go to
3. click through and check that the send codec is VP9 using webrtc-internals
4. click the "create offer" and "set offer" buttons
5. set the _current_ remotePeerConnections localDescription (which still contains VP9) as the localPeerConnections remotedescription:
5. localPeerConnection.setRemoteDescription(remotePeerConnection.remoteDescription, function () { console.log('oh no'); }, function (err) { console.log('RFC 3264 forever!!!', err); })

What is the expected result?
setRemoteDescription fails. Quoting JSEP (since searching for 'subset' in RFC 3264 does not yield the text I want):
   [...] the answer is not permitted to expand capabilities and therefore will just respond to what is actually in the offer.

What do you see instead?
setRemoteDescription succeeds.

Additionally, googCodecName is still VP9 in getStats/webrtc-internals. But the actual send bitrate is zero because the cam in my VM is not recognized so that _might_ just be not updated. If it is still used as the send codec that would be bad.

What version of the product are you using? On what operating system?
Google Chrome	41.0.2229.1 (Official Build) canary
Revision	e53a966164b2f51616a61666a6fae26c4bce2127-refs/branch-heads/2229@{#1}
OS	Windows 

Please provide any additional information below.
I ran out of bugspray recommended for doing stuff with VP9.

Comment 1 by, Nov 27 2014

Project Member
I didn't get the point of this test.
First of all, this has nothing to do with vp9 support. I could see the problem with Chrome Stable too.
And the error message is "RFC 3264 forever!!! Failed to set remote offer sdp: Called in wrong state: STATE_SENTINITIATE". It's about the state at SRD.
And it seems that remotePeerConnection.remoteDescription doesn't equal to the Answer which should be created at renegotiation.

Please help to clarify!

Comment 2 by, Nov 27 2014

ah, the code in step 5 should be:
localPeerConnection.setRemoteDescription(remotePeerConnection.localDescription, function () { console.log('oh no'); }, function (err) { console.log('RFC 3264 forever!!!', err); })
(i.e. remotePeerConnection._localDescription_ instead of .remoteDescription). Sorry about that.

This isn't introduced by a VP9 change, I just happened to stumble over that. The same thing happens when removing opus from audio, tested in good old chromium 37.
Actually I saw opus still being received in that case.

I'm expecting chrome not to accept the protocol violation here.

Comment 3 by, Nov 27 2014

Project Member
I still couldn't get the point.
If I call "localPeerConnection.setRemoteDescription(remotePeerConnection.localDescription, function () { console.log('oh no'); }, function (err) { console.log('RFC 3264 forever!!!', err); })" in step 5, it works. I get the 'oh no' log.

What's the difference you're mentioning between  "remotePeerConnection.localDescription" and the Answer if I click 'create answer' in step 5?

Comment 4 by, Nov 27 2014

"create answer" is the happy path. The peer does what it is expected to (create an answer that is a subset of the offer) and everything is fine.

This is a "bad path" example. The "oh no" indicates that Chrome has accepted the "expanded capabilities" (in JSEP language) in the answer. 
Which would be just a spec violation (of JSEP) if chrome would switch the codec back to the one supported both in its offer and answer. It currently seems to be happy knowing that it supports VP9 (or opus) and does not take into account that this codec was removed in the SLD call (which JSEP allows, "Remove or reorder codecs"). Not really critical, probably something for the sdp icebox :-)

Actually (surprise), RFC 3264 allows additional codecs in the answer, see
which slightly conflicts with JSEP. Justin?

Comment 5 by, Nov 28 2014

Project Member
Labels: Area-PeerConnection
Thanks for the clarification. I finally got you guys.

Since I couldn't enable vp9 in my Canary, so the reproduction steps could be adjusted as you suggests:

In step4, after 'create offer', remove opus from m=line and relevant a= lines, then 'set offer'.
In step5, in console do: localPeerConnection.setRemoteDescription(remotePeerConnection.localDescription, function () { console.log('oh no'); }, function (err) { console.log('RFC 3264 forever!!!', err); })

Since the remotePeerConnection.localDescription still contains opu in the list which is already removed in new offer, so according to JSEP(where it is stated?), SLD should fail.

And yes in RFC3264, this is allowed as:
The stream MAY indicate additional media formats, not listed in the
   corresponding stream in the offer, that the answerer is willing to
   send or receive (of course, it will not be able to send them at this
   time, since it was not listed in the offer)

@justin, please help to confirm if this is an issue!

Comment 6 by, Dec 11 2014

Project Member
Trying to summarize, the problem is:
offer1: VP8, VP9
answer1: VP8
offer2: VP8,
answer2: VP9, VP8 ---> should be just 'VP8'?

Comment 7 Deleted

Comment 8 by, Dec 11 2014

answer2 should be VP8 only (in most cases) but chrome chooses VP9 even though it was not in the localdescription of offer2

Comment 9 by, Dec 12 2014

Project Member
Labels: EngTriaged
Status: Available
Sounds like we need some function to verify that an answer is consistent with its offer.

Comment 10 by, Dec 12 2014

more like creating the intersection between the answer and the localdescription. I would expect createAnswer to already contain such code.

Comment 11 by, Dec 12 2014

Project Member
I meant on the offerer side

Comment 12 by, Dec 12 2014

err... and I meant reusing code that should be somewhere in createAnswer (calculating the intersection between the offer and the local capabilities) on the offerer side in setRemoteDescription w/type=answer.

Comment 13 by, Mar 29 2016

March 2016. Any update to this? What is the current status?

Comment 14 by, Nov 8 2016

Project Member
Labels: Pri-3

Comment 15 by, Dec 14 2016

Project Member
Owner: ----

Comment 16 by, Jan 15 2018

while i have the feeling that i'm talking to myself mostly: see also #8462 which suggests that such a thing is both legal and required.

Comment 17 by, Jan 15 2018

Project Member
Status: WontFix (was: Available)
So it seems that this bug is overtaken by events based on since the complained-about behavior is now the required one.

Won't fix, then.

Sign in to add a comment