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

Issue 4040 link

Starred by 6 users

Issue metadata

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



Sign in to add a comment

subsequent answer with a codec not in the offer succeeds

Reported by fi...@andyet.net, Nov 25 2014

Issue description

What steps will reproduce the problem?
Similar to to #4037:
1. enable VP9 support
2. go to http://googlechrome.github.io/webrtc/samples/web/content/peerconnection/munge-sdp/
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.
 
Project Member

Comment 1 by braveyao@webrtc.org, Nov 27 2014

Owner: braveyao@webrtc.org
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!
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.
Project Member

Comment 3 by braveyao@webrtc.org, Nov 27 2014

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?
"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 http://tools.ietf.org/html/rfc3264#section-6.1
which slightly conflicts with JSEP. Justin?
Project Member

Comment 5 by braveyao@webrtc.org, Nov 28 2014

Cc: braveyao@webrtc.org
Labels: Area-PeerConnection
Owner: juberti@webrtc.org
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!
Project Member

Comment 6 by juberti@webrtc.org, Dec 11 2014

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


Comment 7 Deleted

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

Comment 9 by juberti@webrtc.org, Dec 12 2014

Cc: juberti@webrtc.org
Labels: EngTriaged
Owner: pthatcher@webrtc.org
Status: Available
Sounds like we need some function to verify that an answer is consistent with its offer.
more like creating the intersection between the answer and the localdescription. I would expect createAnswer to already contain such code.
Project Member

Comment 11 by juberti@webrtc.org, Dec 12 2014

I meant on the offerer side
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 ibc@aliax.net, Mar 29 2016

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

Comment 14 by pthatcher@webrtc.org, Nov 8 2016

Labels: Pri-3
Project Member

Comment 15 by anatolid@webrtc.org, Dec 14 2016

Cc: pthatcher@webrtc.org
Owner: ----
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.
Project Member

Comment 17 by hta@webrtc.org, Jan 15 2018

Status: WontFix (was: Available)
So it seems that this bug is overtaken by events based on https://bugs.chromium.org/8462 since the complained-about behavior is now the required one.

Won't fix, then.


Sign in to add a comment