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 5 users
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 Back to list
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