W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > April 2018

Re: [webrtc-pc] should RTCRtpSender.setParameters invalidate LastReturnedParameters?

From: Bernard Aboba via GitHub <sysbot+gh@w3.org>
Date: Fri, 27 Apr 2018 23:27:16 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-385118130-1524871634-sysbot+gh@w3.org>
@taylor-b Since writeable parameters cannot set the `negotiationneeded` flag, those parameters cannot be invalidated (or even changed) by SLD/SRD.  So I think we only need to look at read-only parameters (rid).  For example, consider the sender side: 

dictionary RTCRtpSendParameters : RTCRtpParameters {
    required DOMString                          transactionId;
    required sequence<RTCRtpEncodingParameters> encodings;
             RTCDegradationPreference           degradationPreference = "balanced";

Neither SRD nor SLD change `degradationPreference`, correct?  With respect to encoding parameters, we have: 

dictionary RTCRtpEncodingParameters : RTCRtpCodingParameters {
    octet           codecPayloadType;
    RTCDtxStatus    dtx;
    boolean         active = true;
    RTCPriorityType priority = "low";
    unsigned long   ptime;
    unsigned long   maxBitrate;
    double          maxFramerate;
    double          scaleResolutionDownBy;

It looks to me like the rid attribute (read-only) can be changed by SLD/SRD.  codecPayloadType attribute 
is used to select a codec to be sent.  An invalid value could be chosen, but assuming it is one of the codecs from createOffer/SLD, nothing should change.  If an Answer selects another codec, would codecPayloadType change when SRD is called?  

For the receiver, situation is somewhat more unclear, since I'm not sure why we need the rid attribute in RTCRtpDecodingParameters, or whether a codecPayloadType attribute is needed there.

GitHub Notification of comment by aboba
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1857#issuecomment-385118130 using your GitHub account
Received on Friday, 27 April 2018 23:27:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:01 UTC