Open Bug 1055080 Opened 7 years ago Updated 2 years ago

H264 fmtp in SDP from about:webrtc differs from SDP returned by createOffer/Answer

Categories

(Core :: WebRTC, defect)

34 Branch
defect
Not set
normal

Tracking

()

Blocking Flags:
backlog parking-lot

People

(Reporter: drno, Unassigned)

References

(Blocks 3 open bugs)

Details

Attachments

(2 files)

Attached file console.log.txt
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.
Attached file aboutwebrtc.txt
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
Blocks: webrtc_spec
backlog: --- → parking-lot
Blocks: 1624328
You need to log in before you can comment on or make changes to this bug.