Additional STUN Candidate for RTCP

You can configure the ESBC to establish a collapsed flow between itself and any STUN endpoint by enabling the rtcp-stun parameter in the applicable ice-profile. The system uses this flow for both RTP and RTCP, collapsing this traffic from two ports. As such, this configuration only applies when you have a realm supporting STUN with rtcp-mux disabled.

Although RTCP multiplexing can simplify advanced media deployments that use NAT, it does not adhere to the RFC 5245 requirements for ICE LITE. These requirements include using separate ports for RTP and RTCP. You use this configuration for ICE LITE deployments within which other components of the infrastructure require separate RTP and RTCP ports. When you enable rtcp-stun and leave rtcp-mux at its default of disabled, ESBC behavior when it receives an INVITE that includes ICE includes:

• The source IP of RTCP STUN request is the same as the source IP of the RTP STUN request
• The source port of RTCP STUN request is (RTP STUN request port + 1)

  Your RTP port should always be an EVEN port number, and RTP+1 is always ODD.

• The destination IP of RTCP STUN request is the same as the destination IP of the RTP STUN request
• The destination port of RTCP STUN request is (RTP STUN request port + 1)

  Your RTP port should always be an EVEN port number, and RTP+1 is always ODD.

ICE deployment configuration includes enabling rtcp-stun on the ice-profile, applying that ice-profile to the applicable realms, and disabling rtcp-mux on both of your ICE call flow realms.

When you have configured this feature, applicable call signaling proceeds as follows:

1. The ESBC initiates ICE operation when it receives an INVITE that includes SDP with ICE attributes, effectively asking for an ICE call setup. This INVITE would also include two media candidates.
2. The ESBC sends its own INVITE towards the callee, requesting ICE and providing two media candidates.
3. If the callee can support ICE, it responds by accepting the call.
4. After accepting, the callee issues an RTP STUN request to the RTP port advertised by the ESBC.
5. Having received this request, the ESBC replies with a STUN Bind Success Response and instantiates the RTP and RTCP flows. The system can then begin transmitting RTP and RTCP between the negotiated ports.
6. The callee issues an RTCP STUN request to the RTCP port.
7. Having received this request, the ESBC replies with a STUN Bind Success Response.
8. When the callee sends periodic RTCP STUN requests, the ESBC replies with success responses. These exchanges can be understood as a keepalive function.

Early STUN Bind Requests

In some call flows, the ICE end station may issue a STUN bind request prior to the call's 200 OK. In these cases, the ESBC behavior is dependent on the type of bind request.

The call flow below presents this scenario with an RTP bind request. In this case, the ESBC is able to latch the flow and start sending/receiving RTP media as soon as the 200 OK arrives. The call flow below also has the RTCP bind request arriving after the RTP flows are operational. The ESBC responds by setting up the RTCP flow upon its successful bind reply.

If, however, the early bind request was for RTCP, the ESBC would not queue the RTCP channel for setup after the 200 OK. In this case, the ESBC needs to wait for the RTP bind request and issue a successful reply. As soon as the RTP bind request is successful, the ESBC starts passing both RTP and RTCP media.

Feature Limitations

This section presents limitations to the Additional STUN Candidate for RTCP feature.

1. This feature works only when rtcp-mux is disabled on both the incoming and outgoing realms.
2. hnt-rtcp and rtcp-stun (Ice-lite feature flag) both are mutually exclusive. Make sure you disable your hnt-rtcp configuration when the Ice lite feature is enabled, and vice-versa.
3. Since the ESBC does not support Teams to Teams calls, the Ice-lite feature does not support Teams to Teams scenarios.
4. The skip-ice option is not supported by this feature.
5. For MPO scenarios that include Proxy and Downstream ESBCs in the path:
   • Make sure that the ice-profile configuration on each ESBC is the same. This feature does not work properly if you have enabled rtcp-stun on one ESBC but not on the other.
   • Disable the ICE configuration on the realm of the proxy ESBC that faces the downstream ESBC.
6. The following two scenarios are not supported by this feature because they are not supported on existing MS Teams implementation.
   • When handling an incoming call put on hold from the MS-Teams side, RTP and RTCP should flow towards the PSTN before the hold, but only RTCP should flow towards MS-Teams after the hold. After MS-Teams resumes the call, RTP and RTCP should flow both sides.
   • When handling an outgoing call put on hold from the MS-Teams side, RTP and RTCP should flow towards the PSTN before the hold, but only RTCP should flow towards MS-Teams after the hold. After MS-Teams resumes the call, RTP and RTCP should flow both sides.
7. This feature is not supported, if the endpoint on whose realm this feature flag is enabled sends an ODD media port for the RTP exchange in the offer/answer SDP. In this scenario, the ESBC returns a 503 error towards the endpoint.