If the MRFC receives a SDP Offer containing ECN negotiation, see
RFC 6679, and the MRFC and MRFP support ECN and at least some of the initialisation methods offered within the
"a=ecn-capable-rtp" attribute,
the MRFC shall:
-
act as an end point for ECN;
-
return a SDP Answer according to TS 26.114 and the capabilities of the MRFP, containing the "a=ecn-capable-rtp" attribute; and
-
indicate to the MRFP that it shall apply the ECN procedures (according to TS 26.114) and act as an ECT endpoint.
When creating the SDP Offer the MRFC may initiate ECN negotiation (in accordance with
TS 26.114), indicating the capabilities of the MRFP.
If the MRFC receives the SDP Answer also containing ECN attributes (indicating successful ECN negotiation) then it shall indicate to the MRFP that it shall apply the ECN procedures (according to
TS 26.114) and act as an ECT endpoint.
The following ECN parameters are preconfigured in the MRFP:
-
Initialisation = "leap";
-
Mode = "setread";
-
ECT Marking = ECT-0;
-
Feedback is via Application Specific Adaptation Requests (i.e. Receiver Driven Congestion Control).
The MRFP should not send RTCP XR ECN summary reports.
The procedure to configure the MRFP for ECN may be combined with any other procedure requesting media resource from the MRFP.
Figure 6.2.14.2.1 shows the message sequence chart example for requesting Explicit Congestion Notification.
Upon receipt of a request to apply Explicit Congestion Notification the MRFP shall set the ECN field of the IP header in accordance with
TS 26.114 when sending any data packets.
Upon receipt of any IP headers indicating Congestion Experienced (ECN-CE) the MRFP shall trigger rate adaptation in accordance with
TS 26.114.
Figure 6.2.14.3.1 shows the message sequence chart example for ECN Failure Event.
When the MRFC receives a Notification indicating that an error has occurred it may trigger a new SDP offer to remove ECN.