================
6.7.2 (May 2018)
================



Added
=====

- *WebRtcEndpoint* now allows to specify the desired direction for generated SDP Offers.

  The most common use case for WebRTC calls is to generate an SDP Offer in the Browser and then pass it over to process in Kurento (which in turn generates an SDP Answer). However the opposite workflow is also possible: to have Kurento generating the SDP Offer, with the browser being the one which gets to process it.

  This feature has been part of Kurento for a while, but there was a small bit missing in the picture: the SDP Offers generated by Kurento had always the *direction* attribute set for a two-way media stream, i.e. both receiving and sending media. Now, it is possible to configure the *WebRtcEndpoint* to generate SDP Offers with all three possible directions: ``a=sendrecv``, ``a=sendonly``, ``a=recvonly``, for send-receive, send-only, and receive-only, respectively.



Changed
=======

- *WebRtcEndpoint* now doesn't use reduced minimum interval for RTCP packets when the :term:`REMB` network congestion control algorithm is not in use.

  :rfc:`3550` section 6.2 (*RTCP Transmission Interval*) recommends an initial value of 5 seconds for the interval between sending of RTCP packets. However, Kurento configures a much lower value, and RTCP packets are sent every 500 milliseconds. The reasoning for this is that the congestion control algorithm (REMB) should be able to react as soon as possible when congestion occurs, and this is helped by a faster RTCP interval.

  The use case for this change is audio-only calls; Kurento doesn't support using the network congestion algorithm for audio streams, so it doesn't make sense to force sending high-frequency RTCP packets in this case. This has the secondary effect of greatly reducing consumed bandwidth when an audio track is muted via one of the browser's *RTCPeerConnection* methods.



Fixed
=====

- Send mandatory attribute ``a=setup:actpass`` in SDP Offers. :rfc:`3550` section 5 (*Establishing a Secure Channel*) states:

  .. code-block:: text

     The endpoint that is the offerer MUST use the setup attribute
     value of setup:actpass

  This was not the case in Kurento; Chrome was permissive about this mistake, but Firefox was complaining about the lack of this attribute in SDP Offers generated by the *WebRtcEndpoint*.