1555808 - Decoder(VP8:PT=120) and Encoder(VP8:PT=102) have different PT

Status: RESOLVED INVALID

(Core :: WebRTC, defect)

Description

[Pradeep Kumar]

Attachment: FF69.log

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36

Steps to reproduce:

1. Do createOffer(), you got the sdpOffer created.
2. Modify the sdpOffer for VP8 PT from 120 to 102.
3. Set the new sdpOffer to PeerConnection.
4. Set the remote sdpAnswer into PeerConnection once received.
   5)Let the call established.

Actual results:

Firefox is not able to decode the RTP received from another client.

Expected results:

Firefox should be able to decode the RTP from another client.

Comment 1

[Pradeep Kumar]

My Observation:

While testing our application with Firefox68, we found the following issue.

1. We are using Payload type of VP8 codec as 102 for our application.
2. For the same, we do modify the SDP before testing LocalSessionDescription into PeerConnection.
3. Based on that, FF is able to create a Video encoder with payload type = 102.
4. But, doesn’t create Video Decoder with payload type - 102.

Decoder created as follow with PT-120
2019-05-30 18:07:40.927292 UTC - [Child 14099: Main Thread]: D/webrtc_trace (video_receive_stream.cc:109): VideoReceiveStream: {decoders: [{decoder: (VideoDecoder), payload_type: 120, payload_name: VP8, codec_params: {}}], rtp: {remote_ssrc: 187674659, local_ssrc: 3677229644, rtcp_mode: RtcpMode::kCompound, rtcp_xr: {receiver_reference_time_report: off}, remb: off, transport_cc: off, nack: {rtp_history_ms: 0}, ulpfec_payload_type: -1, red_type: -1, rtx_ssrc: 0, rtx_payload_types: {}, extensions: [{uri: http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time, id: 4}]}, renderer: (renderer), render_delay_ms: 10, sync_group: stream_label, pre_decode_callback: nullptr, target_delay_ms: 0}

Encoder as follow with PT-102
2019-05-30 18:07:40.927796 UTC - [Child 14099: Main Thread]: D/webrtc_trace (overuse_frame_detector.cc:98): Number of physical cores:6
2019-05-30 18:07:40.927991 UTC - [Child 14099: Unnamed thread 0x14d65be30]: D/webrtc_trace (video_send_stream.cc:742): VideoSendStreamInternal: {encoder_settings: {payload_name: VP8, payload_type: 102, encoder: (VideoEncoder)}, rtp: {ssrcs: [3677229644], rtcp_mode: RtcpMode::kCompound, max_packet_size: 1200, extensions: [{uri: http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time, id: 4}], nack: {rtp_history_ms: 1000}, ulpfec: {ulpfec_payload_type: -1, red_payload_type: -1, red_rtx_payload_type: -1}, flexfec: {payload_type: -1, ssrc: 0, protected_media_ssrcs: []}, rtx: {ssrcs: [], payload_type: -1}, c_name: {56434b6e-b10c-c540-85af-9fe0d6c7fbb5}}, pre_encode_callback: nullptr, post_encode_callback: nullptr, render_delay_ms: 0, target_delay_ms: 0, suspend_below_min_bitrate: off}

So, problem seems to be that, FF is not adhering to the SDP set into the PeerConnection, but keeps doing stuff based on what it had created while doing createOffer api call as I can see that PT is set to 120 for VP8 on the initial createdOffer.

Please, let me know if logs are needed in case anyone of you not able to recreate this.
Frequency = 100%

Comment 2

[Eric Rescorla (:ekr)]

You are violating the JSEP specification, which forbids changing the SDP.

   The SDP returned from createOffer or createAnswer MUST NOT be changed
   before passing it to setLocalDescription.  If precise control over
   the SDP is needed, the aforementioned createOffer/createAnswer
   options or RtpTransceiver APIs MUST be used.

https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26#section-5.4

It does appear that Firefox is failing to follow the requirement to reject this in the WebRTC spec (https://w3c.github.io/webrtc-pc/#set-the-rtcsessiondescription) however even if Firefox did so, it still wouldn't make your use case work.

Comment 3

[Eric Rescorla (:ekr)]

Nils, is failing to throw InvalidModificationError in this case a known defect?

Comment 4

[Pradeep Kumar]

(In reply to Eric Rescorla (:ekr) from comment #2)

You are violating the JSEP specification, which forbids changing the SDP.

   The SDP returned from createOffer or createAnswer MUST NOT be changed
   before passing it to setLocalDescription.  If precise control over
   the SDP is needed, the aforementioned createOffer/createAnswer
   options or RtpTransceiver APIs MUST be used.

https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26#section-5.4

It does appear that Firefox is failing to follow the requirement to reject this in the WebRTC spec (https://w3c.github.io/webrtc-pc/#set-the-rtcsessiondescription) however even if Firefox did so, it still wouldn't make your use case work.

Thanks Eric,
Seems, this change happened to be from FF68 or 69 some where, as FF67 is working fine.
Anyway, need a bit help, is it possible to change the codec PT thru RtpTransceiver in JS code and how?

Comment 5

[Pradeep Kumar]

@Eric, Furthermore, why we are creating decoder and encoder with different PT? How I can force to use the same PT to be used for both Encoder and Decoder.
As FF is not raising the Error while we are modifying the SDP before setting to setLocalDescriptionm why it is not able to handle the changed SDP. Is there something wrong in the newer FF 68/69? The same is working on F67.

Comment 6

[Nils Ohlmeier [:drno]]

@Ekr I created bug 1565712 for implementing the missing InvalidModificationError

Comment 7

[Nils Ohlmeier [:drno]]

Pradeep modifying the SDP in between createOffer() and setLocalDescription() has never been officially supported by Firefox. It was unfortunately the only wait to achieve certain features with Chrome. But the WebRTC specs don't allow this not any more. So all WebRTC browser will sooner or later reject modified SDP.

And yes setParameters() https://www.w3.org/TR/webrtc/#rtcrtpsender-interface allows you to specify your desired PT. But note that this has not yet been implemented in Firefox.

My counter question is: why do you need to force Firefox to use a certain PT? Why can't the other endpoint not dynamically negotiate the PT? Do you know that RTP and SDP allow negotiating PT asymmetrically (so sending and receiving PT don't have to be the same)?

Note: I'm going to close this bug as invalid, because there isn't anything to fix on the Firefox side.