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

Issue 2063 link

Starred by 21 users

Issue metadata

Status: Assigned
Last visit > 30 days ago
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Sign in to add a comment

sdp version on o= line ignored by .setLocalDescription and .setRemoteDescription

Reported by, Jul 10 2013

Issue description

While playing around with muting by setting a=inactive i noticed some oddities. A repeated call to .setLocalDescription doesn't seem to honor the SDP version on the o= line.

I have two ways of muting... javascript snippets that can be pasted into the console on apprtc are attached. Note that currently this way of muting doesn't work when DTLS is enabled because of  issue #1718  so you need to do pcConstraints = {} by break'ing before createPeerConnection() on apprtc.

the bad way (snippet in badway.txt) takes the peerconnections .localDescription property, does a string replace and calls .setLocalDescription. 
A chrome://webrtc-internals log from apprtc is attached as badway_log_apprtc.txt. 
I'd expect setLocaldescription to fail because of
	If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number. 

Now, when doing it properly (snippet in createofferway.txt) by calling createOffer before setLocaldescription this increments the version number. Works fine, see createofferway_log_apprtc.txt. In this case, I think .setRemoteDescription isn't behaving in a compliant way because it accepts a modified sdp with the same version. Additionally, the version in the answer doesn't even match the version in the offer.

I'll save a rant that muting shouldn't require O/A ;-)
849 bytes View Download
35.6 KB View Download
1.1 KB View Download
134 KB View Download
Project Member

Comment 1 by, Jul 11 2013

@ronghua, PTAL!
Project Member

Comment 2 by, Jul 11 2013

Labels: Area-PeerConnection

Comment 3 by, Jul 11 2013

Labels: Mstone-30

Comment 4 by, Jul 11 2013

Status: Assigned

Comment 5 by, Aug 12 2013

Labels: -Mstone-30 Mstone-31

Comment 6 by, Sep 23 2013

Labels: -Mstone-31 Mstone-32

Comment 7 by, Nov 8 2013

Labels: -Mstone-32 Mstone-33

Comment 8 by, Jan 4 2014

Labels: -Mstone-33 Mstone-34
Project Member

Comment 9 by, May 21 2014

Ronghua, should we update the milestone on this?

Comment 10 by, May 21 2014

Labels: -Mstone-34 Mstone-38

Comment 11 by, Jul 25 2014

Labels: -Mstone-38 sdp

Comment 12 by, Jul 28 2014

Assign to Peter for triage.
Project Member

Comment 13 by, Oct 16 2014

Labels: IceBox EngTriaged
Just to make the bug more clear:  Chrome seems to be ignoring the version in the o= line.  The expected behavior is to return/throw an error when the version in the o= line is wrong.  
Project Member

Comment 14 by, Nov 4 2015

This bug hasn't been modified for more than a year. Is this still a valid open issue?
hey Ted,
it's a spec-nit. Easier repro:
after establishing a call pasting:
pc1.setLocalDescription(new RTCSessionDescription({type: 'offer', sdp: pc1.localDescription.sdp.replace('a=group:BUNDLE audio video\r\n', '')})).then(function() { console.log('yay'); }).catch(function(err) { console.log(err); })
still results in 'yay'.

I actually like the behaviour (because I do not want to update the version) but it's not compliant. Maybe move from icebox to deep-freeze? :-)
Project Member

Comment 16 by, Dec 28 2015

Project Member

Comment 17 by, Nov 11 2016

Labels: -Pri-2 Pri-3

Sign in to add a comment