Project: webrtc Issues People Development process History Sign in
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 15 users
Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
OS: ----
Pri: 3
Type: Bug
sdp



Sign in to add a comment
sdp version on o= line ignored by .setLocalDescription and .setRemoteDescription
Reported by philipp....@gmail.com, Jul 10 2013 Back to list
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
http://tools.ietf.org/html/rfc3264#section-8
	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 ;-)
 
badway.txt
849 bytes View Download
badway_log_apprtc.txt
35.6 KB View Download
createofferway.txt
1.1 KB View Download
createofferway_log_apprtc.txt
134 KB View Download
Project Member Comment 1 by braveyao@webrtc.org, Jul 11 2013
Cc: braveyao@webrtc.org vikasmarwaha@webrtc.org
Owner: wu@webrtc.org
@ronghua, PTAL!
Project Member Comment 2 by juberti@webrtc.org, Jul 11 2013
Labels: Area-PeerConnection
Comment 3 by wu@webrtc.org, Jul 11 2013
Labels: Mstone-30
Comment 4 by wu@webrtc.org, Jul 11 2013
Status: Assigned
Comment 5 by wu@webrtc.org, Aug 12 2013
Labels: -Mstone-30 Mstone-31
Comment 6 by wu@webrtc.org, Sep 23 2013
Labels: -Mstone-31 Mstone-32
Comment 7 by wu@webrtc.org, Nov 8 2013
Labels: -Mstone-32 Mstone-33
Comment 8 by wu@webrtc.org, Jan 4 2014
Labels: -Mstone-33 Mstone-34
Project Member Comment 9 by vikasmarwaha@webrtc.org, May 21 2014
Ronghua, should we update the milestone on this?
Comment 10 by wu@webrtc.org, May 21 2014
Labels: -Mstone-34 Mstone-38
Comment 11 by wu@webrtc.org, Jul 25 2014
Labels: -Mstone-38 sdp
Comment 12 by wu@webrtc.org, Jul 28 2014
Owner: pthatcher@webrtc.org
Assign to Peter for triage.
Project Member Comment 13 by pthatcher@webrtc.org, 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 tnakamura@webrtc.org, Nov 4 2015
Cc: -vikasmarwaha@webrtc.org
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:
on https://webrtc.github.io/samples/src/content/peerconnection/pc1/
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 tnakamura@webrtc.org, Dec 28 2015
Cc: hta@webrtc.org
Project Member Comment 17 by deadbeef@webrtc.org, Nov 11 2016
Labels: -Pri-2 Pri-3
Sign in to add a comment