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

Issue 4957 link

Starred by 23 users

Issue metadata

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

Sign in to add a comment

an offer m-line not containing any known codecs results in an error

Reported by, Aug 30 2015

Issue description

What steps will reproduce the problem?
1. paste the following JS snippet into the console 
(modified offer from FF with VP8 removed):
var sdp = 'v=0\r\no=mozilla...THIS_IS_SDPARTA-40.0.3 4775435010310862152 2 IN IP4\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 2F:9C:4C:28:DE:38:3E:58:31:B7:7E:28:4C:43:6A:E8:77:BD:25:31:BE:D5:48:32:A5:C3:DF:19:7D:FE:73:EB\r\na=group:BUNDLE sdparta_0\r\na=ice-options:trickle\r\na=msid-semantic:WMS *\r\nm=video 9 RTP/SAVPF 126 97\r\nc=IN IP4\r\na=recvonly\r\na=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1\r\na=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1\r\na=ice-pwd:dc78209f68e7d868307aa6befbd632a6\r\na=ice-ufrag:b87818e9\r\na=mid:sdparta_0\r\na=rtcp-fb:126 nack\r\na=rtcp-fb:126 nack pli\r\na=rtcp-fb:126 ccm fir\r\na=rtcp-fb:97 nack\r\na=rtcp-fb:97 nack pli\r\na=rtcp-fb:97 ccm fir\r\na=rtcp-mux\r\na=rtpmap:126 H264/90000\r\na=rtpmap:97 H264/90000\r\na=setup:actpass\r\na=ssrc:3593351281 cname:{ccbcb38d-6688-4c2f-ad04-2a89e42eeda8}\r\n';
var pc = new webkitRTCPeerConnection(null); pc.setRemoteDescription(new RTCSessionDescription({type: 'offer', sdp: sdp}), function () { console.log('yay'); }, function (err) { console.log('nay', err); })

What is the expected result?
The SRD success callback is called. CreateAnswer generates an answer with the port set to 0 per

This is also how Firefox behaves with an offer containing the H268 and VP12 codecs.

What do you see instead?
The SRD failure callback is called:
Failed to set remote offer sdp: Session error code: ERROR_CONTENT. Session error description: Failed to set video send codecs..

What version of the product are you using? On what operating system?
46.0.2490.6 (Offizieller Build) dev (64-Bit) on linux.

Please provide any additional information below.
I wouldn't be surprised to find bugs with the offerer handling of answers with rejected m-lines.
Project Member

Comment 1 by, Sep 1 2015

Labels: Area-PeerConnection
Yes we currently reject it due to no supported codec founded and set error info here,

@pthatcher, please help to take a look!
Project Member

Comment 2 by, Sep 2 2015

Labels: Spec-IETF EngTriaged
What SetRemoteDescription does is really part of JSEP, not RFC 3264.   But it currently says:

5.8.  Applying a Remote Description


I'm guessing that what we should do, and what we'll end up doing, is that if you apply a remote description that the corresponding RtpSender or RtpReceiver can't handle, then it will go into a closed() state, and the next createOffer or createAnswer will create a rejected m-line.  But we'll have to wait until JSEP is done to know for sure. 
Project Member

Comment 3 by, Sep 14 2015

I agree with the proposed fix in the original report.
Project Member

Comment 4 by, Sep 15 2015

When this is fixed: add a content_browsertest to, and set up a call with no known codecs in the m-line, and ensure the right callback gets called.
Project Member

Comment 5 by, Sep 15 2015

Status: Assigned
Project Member

Comment 6 by, Sep 15 2015

What I'm suggesting we do in #2 achieves the fix in the original report and the suggestion in #3.  Basically, once we implement setRemoteDescription and createAnswer in terms of RtpSenders, do the following:

1.  setRemoteDescription creates an RtpSender.  If the codecs are incompatible, it calls stop() on the entire RtpTransceiver (or whatever we end up calling the sender/receiver pair), but setRemoteDescription still succeeds.
2.  The next time createAnswer is called, port 0 is generated.

Comment 7 by, Oct 4 2015

The actual SDP was more like this btw, I don't really care 
m=video 9 UDP/TLS/RTP/SAVPF 122 123
c=IN IP4
a=rtcp:9 IN IP4
a=rtpmap:122 X-H264UC/90000
a=rtcp-fb:122 x-message app send:src,x-pli recv:src,x-pli
a=rtpmap:123 x-ulpfecuc/90000
a=fingerprint:sha-256 73:FE:E6:60:D6:39:FB:97:26:2C:35:A1:69:7A:99:DA:F0:EE:A8:DD:9F:4F:B9:26:B2:A5:B4:22:3C:28:F3:1D
a=msid:E7B56045-8BA1-4F94-B37F-2BAA12EC11B4 50969317-7D11-4BFD-A516-C6BFCC58A5A0
a=ssrc:3003 msid:E7B56045-8BA1-4F94-B37F-2BAA12EC11B4 50969317-7D11-4BFD-A516-C6BFCC58A5A0
a=ssrc:3003 cname:uhlcxrgm9s


@pthatcher: does step 1 call ontrack with the RtpReceiver's track? The track should (hopefully) be stopped at that point?

Comment 8 by, Oct 4 2015

(err... don't really care about H268 and VP12)
Project Member

Comment 9 by, Oct 6 2015

I think it would fire ontrack, yes.  But the track wouldn't receive anything unless there's a re-offer with codecs that work.
Project Member

Comment 10 by, Jun 3 2016

What's the latest on this?
Project Member

Comment 11 by, Jun 3 2016

Project Member

Comment 12 by, Jun 3 2016

The github version of the spec at is a bit more verbose.

It still doesn't say that an M-line should be rejected when we don't have any valid codecs, but section 5.3.1 "Generating an initial answer" does:

For each offered m= section, if any of the following conditions are true, the corresponding m= section in the answer MUST be marked as rejected by setting the port in the m= line to zero, as indicated in [RFC3264], Section 6., and further processing for this m= section can be skipped:
- The associated RtpTransceiver has been stopped.
- No supported codec is present in the offer.  <===================
- The bundle policy is "max-bundle" and the m= section is not in a bundle group.
- The RTP/RTCP multiplexing policy is "require" and the m= section doesn't contain an "a=rtcp-mux" attribute.

Comment 13 by, Jun 7 2016

for your amusement I have to do something like this now to workaround things:
(ignore the sdp utils on top). Kind of works... ;-)
Project Member

Comment 14 by, Jul 8 2016

ptatcher@ WDYT about this? Do you have cycles to look at it this quarter?
Project Member

Comment 15 by, Nov 8 2016

Labels: Pri-3

Comment 16 by, Nov 8 2016

P3 means that after filing this half a year in advance of it being an actual issue I will have to wait one more year to get it fixed?
Project Member

Comment 17 by, Nov 9 2016

This was part of a mass deprioritization of issues; we can always re-evaluate. The quick evaluation was "this looks like a corner case issue, you can SDP munge to work around it, and even if it occurs the user will be unhappy they get no video".

But if this is impeding Edge interop, maybe it should rank higher. Peter?

Comment 18 by, Jun 20 2017

so with Apple currently not shipping VP8 I tried what happens when you send a VP8-only offer to Safari Technology Preview (which can be achieved by replacing both occurences of "H264" in the sdp from the first comment with "VP8").

It throws the same exception...
apparently this is now also an issue on ios with h264-only offers that do not have a matching (use your ring!) profile-level-id...

I do not understand why this goes unfixed for 2+ years.
Project Member

Comment 20 by, Jan 8 2018

 Issue 5605  has been merged into this issue.
We're facing this issue right now in multiple cases where iOS Safari and Android Chrome 66 are trying to talk together. The problem seems to be from what I can gather that certain Android phones (Huawei Mate 9 for example) only sends VP8, which iOS does not support, resulting in this error.

See attached dump which can be imported into I have attached both sides of the conversation for good measure.

We would love some kind of fix for this if possible, but we will be adding error messages for now.

14.3 KB View Download
16.0 KB View Download
We are facing an increasing amount of issues with this bug as iOS to Android usage increases. It seems the devices (mostly Huawei, but some Sony Xperia phones too) has the required H264 chip onboard, but Chrome can't use it. Any help would be much appreciated for finding a workaround should it be possible.
#22: you are in the wrong bug. Please complain in the one about the lack of a h264 software encoder.

Sign in to add a comment