According to about:webrtc the remote SDP always seems to contain the following line: a=fmtp:126 PROFILE=0;LEVEL=0;profile-level-id=42e00d;packetization-mode=1;level-asymmetry-allowed=1;parameter-add=1;usedtx=0;stereo=0;useinbandfec=0;cbr=0 But according to console.log and double checking the SDP being send through the signaling server the actual line in the offer/answer looked like this: a=fmtp:126 profile-level-id=42e00d;packetization-mode=1 Note: both sides of the call show this difference in the remote SDP vs. what they received.

Go to http://mozilla.github.io/webrtc-landing/pc_test.html start an H264 call and compare the offer and answers in the page log with about:webrtc

So the problem is that the returned RemoteDescription is regenerated from the parsed version plus any trickle candidates. The problem with this as shown below is that we can't guarantee the SDP is the same as what was input (and in fact it isn't due to some internal issues with SIPCC). This likely violates the draft spec. We *should* record the SDP, and then add to it any trickle candidates added. 17:23 jesup yeah, you can't take the output of parse and feed it back into generation and get the same string I believe 17:25 jesup basically it throws in the 'default' values for all sorts of parameters if you feed the parse back in 17:45 jesup drno: this appears to be the callstack for fmtp generation with profile >= 0 (which means it will be output): https://pastebin.mozilla.org/6040331 17:47 jesup drno: note the comment in media/webrtc/signaling/src/sipcc/core/gsm/fsmdef.c:3885 - so if this is used again later, it may be wrong. However this may not be the source of what you're logging. Something like this likely is, though 17:52 jesup which means it's logging a value it retreived from sipcc, not the value passed into SetRemoteDescription (which is what it should return/log) 17:55 jesup drno: jib: bwc: it's getting the remote SDP from the success callback of SetRemoteDescription by asking SIPCC about it; it should set it from the input to SetRemoteDescription (IMHO, and I htink the spec says so) 17:56 jesup case SETREMOTEDESCSUCCESS: 17:56 jesup case ADDICECANDIDATE: 17:56 jesup mRemoteSDP = aInfo->getSDP(); 17:56 * jib has dejavu thinking he just saw a bug on that go by

Other than the potential spec issue, is there a functional problem with the current behavior?

(In reply to Jan-Ivar Bruaroey [:jib] from comment #4) > Other than the potential spec issue, is there a functional problem with the > current behavior? Not really, no, unless someone does something like use that instead of the sdp returned by createOffer/etc