Nils Ohlmeier [:drno] Reporter
	Description • 10 years ago

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.

	Nils Ohlmeier [:drno] Reporter
	Comment 2 • 10 years ago

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

	Randell Jesup [:jesup] (needinfo me)
	Comment 3 • 10 years ago

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

	Jan-Ivar Bruaroey [:jib] (needinfo? me)
	Comment 4 • 10 years ago

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

	Randell Jesup [:jesup] (needinfo me)
	Comment 5 • 10 years ago

(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