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

Issue 3513 link

Starred by 8 users

Issue metadata

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

Sign in to add a comment

SDP parsing: malformed m-lines are ignored

Reported by, Jun 25 2014

Issue description

What steps will reproduce the problem?
1. go to
2. get media, create peerconnections
3. Paste the following line in the console:
localPeerConnection.setRemoteDescription(new RTCSessionDescription({type:'offer', sdp: 'v=0\r\no=- 1403708390493 1403708390496 IN IP4\r\ns=-\r\nt=0 0\r\nm=audio 1 RTP/SAVPF 111 0 8\r\nc=IN IP4\r\na=rtcp:1 IN IP4\r\na=ice-ufrag:7ojd7\r\na=ice-pwd:1s18qkgf3847isjj2e0toits9h\r\na=fingerprint:sha-1 3E:74:7A:70:92:FD:7C:C1:17:85:F9:41:F2:64:D3:09:57:3C:99:2E\r\na=sendrecv\r\na=mid:audio\r\na=rtpmap:111 opus/48000/2\r\na=fmtp:111 minptime=10\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\nm=video 1 RTP/SAVPF 100 116 117\r\nc=IN IP4\r\na=rtcp:1 IN IP4\r\na=ice-ufrag:eoo81\r\na=ice-pwd:3m6folvjvci0rlvkmrec6233av\r\na=fingerprint:sha-1 CB:67:54:6A:17:6D:3D:31:B1:7A:E6:9B:8F:52:99:69:D0:63:ED:84\r\na=sendrecv\r\na=mid:video\r\na=rtpmap:100 VP8/90000\r\na=rtcp-fb:100 ccm fir\r\na=rtcp-fb:100 nack\r\na=rtcp-fb:100 nack pli\r\na=rtcp-fb:100 ccm fir\r\na=rtpmap:116 red/90000\r\na=rtpmap:117 ulpfec/90000\r\nm= 1 RTP/SAVPF\r\nc=IN IP4\r\na=ice-ufrag:bfc8i\r\na=ice-pwd:50gmbq3r0phmqdiuveh0t1pp0l\r\na=fingerprint:sha-1 1C:18:FA:D9:BF:3B:80:E2:02:A6:14:59:EA:22:12:30:A5:0E:25:EF\r\na=mid:data\r\n'}), function () { console.log('success') }, function (err) { console.log('error'); })

What is the expected result?
setRemoteDescription fails because of the malformed m-line
This was supposed to be an m=application line but was... mangled. Obvious workaround is not to pass malformed SDP into it.

What do you see instead?
The success callback is called. createAnswer creates an answer with two m-lines. Changing the order of m-lines so that the malformed one is in the middle is probably an interesting case to test here.

What version of the product are you using? On what operating system?
38.0.2068.0 (Offizieller Build 279517) canary on windows 7
Project Member

Comment 1 by, Jun 25 2014

It seems to be true. And it looks being OK if it's the last m-line being wrong. But if the first audio m-line is wrong, still success callback is called and no media in Answer at all. That doesn't look good.

@wu, please help to comment!

Comment 2 by, Jul 2 2014

Status: Assigned
And I agree we should return an error if the m line looks like "m= 1 RTP/SAVPF", which is against the format defined by RFC. However if the line looks like "m=unknown 1 RTP/SAVPF", I think we should ignore it instead of returning error.

Agree with Brave we have a bug on handling the case when a unsupported m-line is not the last one. We should fix that by moving forward the read pointer to the next m-line, in below code:
Rejecting unknown media types (port = 0) should be more correct for m=unknown. At least unless RFC 4566 is specifying weird things.

Comment 4 by, Jul 25 2014

Labels: sdp

Comment 5 by, Jul 28 2014

Assign to Peter for triage.
Project Member

Comment 6 by, Sep 5 2014

Labels: Area-PeerConnection
Agree with #3

Comment 7 by, Oct 16 2014

Labels: IceBox EngTriaged
Project Member

Comment 8 by, Nov 4 2015

This issue hasn't been modified for more than a year, but I'm still able to trigger the bug using the originally reported repro steps with 48.0.2553.1. Note that the munge SDP page has since moved to
Project Member

Comment 9 by, Nov 8 2016

Labels: Pri-3

Sign in to add a comment