4 Protocol Examples

  • Article

The following figure shows a sample deployment scenario for bandwidth management.

Bandwidth management deployment scenario

Figure 3: Bandwidth management deployment scenario

In the preceding figure, Endpoint L and Endpoint R belong to different sites that are connected via wide area network (WAN) links that are under bandwidth management. Both Endpoint L and Endpoint R are configured with their respective User Datagram Protocol (UDP) bandwidth policy servers that provide Traversal Using Relay NAT (TURN) functionality, in addition to bandwidth policy management servers, LPS for Endpoint L and RPS for Endpoint R.

Both agents are full Interactive Connectivity Establishment (ICE) implementations and use regular nominations for selecting the candidates to be used for media flow. In the following example, WAN Link 1 is congested and does not have bandwidth available for media flow. WAN Link 2 and WAN Link 3 have bandwidth available for media flow.

The transport address follows a similar naming convention to the sample as described in [MS-ICE2] section 4.

Transport addresses are referred to by using mnemonic names with the format entity-type-seqno, where entity refers to the entity whose IP address the transport address is on, and is one of "L", "R", "LPS", or "RPS". The type is either "PUB" for transport addresses that are publicly reachable on the Internet or "PRIV" for transport addresses that are not reachable from the Internet. The seqno is a number that is different for transport addresses of the same type on an entity.

Endpoint L has a private address L-PRIV-1 (192.168.2.1) and Endpoint R has a private address R-PRIV-1 (192.157.2.1).

LPS has a transport address LPS-PRIV-1 on the private edge (192.170.20.1) and external edge with LPS-PUB-1 (10.101.0.57).

RPS has a transport address RPS-PRIV-1 on the internal edge (192.175.54.2) and external edge with RPS-PUB-1 (10.107.0.37).

Definitions for the call flow are as follows:

  • "S=" refers to the source transport address.

  • "D=" refers to the destination transport address.

  • "SD=" refers to the destination address to which the TURN server has to forward the packet.

  • "LSA=" refers to the local site address attribute.

  • "LRA=" refers to the local relay site address attribute.

  • "RSA=" refers to the remote site address attribute.

  • "RRA=" refers to the remote relay site address attribute.

  • "USE-CAND" implies the presence of the USE-CANDIDATE attribute, as described in [IETFDRAFT-ICENAT-19] section 7.1.1.1.

  • "DIS-CAND" implies the presence of the Disable Candidate error code in the message.

  • "DIS-LS" implies that the bandwidth policy server disallows the usage of candidates belonging to the local site.

  • "DIS-RS" implies that the bandwidth policy server disallows the usage of candidates belonging to the remote site.

  • "BW-CHK-REQ" implies the presence of bandwidth admission check request attributes.

  • "BW-CHK-RES" implies the presence of bandwidth admission check response attributes.

  • "BW-CMT-REQ" implies the presence of bandwidth admission commit request attributes.

  • "BW-CMT-RES" implies the presence of bandwidth admission commit response attributes.

  • "RES-ID" implies the presence of the reservation ID attribute.

  • "BW-UPD-REQ" implies the presence of bandwidth admission update request attributes.

  • "MA=" refers to the mapped address in the Simple Traversal of UDP through NAT (STUN) binding response.

  • "RA=" refers to the reflexive address.

  • "TA=" refers to the relay transport address.

For clarity, the example does not show the TURN authentication mechanisms and the Real-Time Transport Control Protocol (RTCP) component.

The example focuses on the Real-Time Transport Protocol (RTP) component for establishing a media session between Endpoint  L and Endpoint R with bandwidth policy management and does not focus on protocol details as described in [MS-TURNBWM].

Endpoint L initiates the media session and becomes the controlling agent because Endpoint L is a full ICE implementation. Endpoint L gathers its UDP Host Candidate by binding to its local interface and then gathers a UDP Relayed Candidate from the configured server, LPS. Because no Transmission Control Protocol (TCP) TURN servers are configured, Endpoint L creates a TCP-ACT Server Reflexive Candidate based on the UDP Host Candidate. After gathering the candidates, Endpoint L sends the INVITE to Endpoint R. A sample INVITE Session Description Protocol (SDP) for Endpoint L's topology is as follows:

 v=0
 o=- 0 0 IN IP4 10.101.0.57
 s=session
 c=IN IP4 10.101.0.57
 b=CT:99980
 t=0 0
 m=audio 52732 RTP/AVP 114 111 112 115 116 4 8 0 97 13 118 101
 a=ice-ufrag:qkEP
 a=ice-pwd:ed6f9GuHjLcoCN6sC/Eh7fVl
 a=candidate:1 1 UDP 2130706431 192.168.2.1 50005 typ host
 a=candidate:2 1 UDP 16648703 10.101.0.57 52732 typ relay raddr 192.168.2.1 rport 50033 a=candidate:4 1 TCP-ACT 1684797951 192.168.2.1 50005 typ srflx raddr 192.168.2.1 rport 50005 a=rtpmap:114 x-msrta/16000

The following figure is the call flow for the RTP component for establishing a media session between Endpoint L and Endpoint R with bandwidth policy management.

RTP component call flow for bandwidth management

RTP component call flow for bandwidth management

Figure 4: RTP component call flow for bandwidth management

Endpoint R, upon receiving the offer, gathers its candidates. Endpoint R is assigned as the bandwidth management endpoint for this session. At this point, Endpoint R is aware of the candidates of the peer endpoint. It gathers its UDP Host Candidate by binding to its local interface and then gathers the UDP Relayed Candidate from the configured bandwidth policy server. In the allocate request sent to the bandwidth policy server endpoint at RPS-PRIV-1, Endpoint R adds bandwidth management check attributes to perform policy checks, as specified in section 3.1.4.8.1.1. Endpoint R populates the Local Site Address attribute with "R-PRIV-1", the Remote Site Address attribute with "L-PRIV-1" because Endpoint R is not behind a network address translation (NAT), and the Remote Relay Site attribute with "LPS-PUB-1". Endpoint R specifies the bandwidth needed for this call in the Bandwidth Reservation Amount attribute, as described in [MS-TURNBWM] section 2.2.3. The bandwidth policy server disables both the local site and remote site address in the allocate response, which includes the Bandwidth Check Response attributes, because Wan Link1 does not have available bandwidth for the media session. Endpoint R gathers its Relayed Candidate "RPS-PUB-2" from the allocate response. Because no TURN TCP servers are configured, Endpoint R creates a TCP-ACT Server Reflexive Candidate based on the UDP Host Candidate.

Endpoint R, based on the policy decision received, does not form candidate pairs for candidates that have been disabled by the bandwidth policy. As a result of the bandwidth policy, Endpoint R has only one candidate pair, which is RPS-PUB-2 to LPS-PUB-2. A sample answer SDP for Endpoint R's topology is as follows:

 v=0
 o=- 0 0 IN IP4 10.107.0.37
 s=session
 c=IN IP4 10.107.0.37
 b=CT:99980
 t=0 0
 m=audio 52714 RTP/AVP 114 111 112 115 116 4 8 0 97 13 118 101
 a=ice-ufrag:qkEP
 a=ice-pwd:ed6f9GuHjLcoCN6sC/Eh7fVl
 a=candidate:1 1 UDP 2130706431 192.175.54.2 50025 typ host
 a=candidate:2 1 UDP 16648703 10.107.0.37 52714 typ relay raddr 192.175.54.2 rport 50036 a=candidate:3 1 TCP-ACT 1684797951 192.175.54.2 50025 typ srflx raddr 192.175.54.2 rport 50025 a=rtpmap:114 x-msrta/16000

Endpoint R starts connectivity checks for its only candidate pair and sends a STUN binding request to LPS-PUB-2 from its Relayed Candidate RPS-PUB-2, which gets dropped at LPS-PUB-2 because permissions have not been opened for RPS-PUB-2 at LPS-PUB-2. This STUN binding request results in permission being opened for LPS-PUB-2 at RPS-PUB-2.

Endpoint L, on receiving the answer, pairs up its candidates with Endpoint R's candidates received in the answer and starts connectivity checks with the highest priority candidate pair. Endpoint L sends a STUN binding request from L-PRIV-1 to R-PRIV-1. Endpoint R, on receiving this STUN binding request from L-PRIV-1, sends a STUN binding error response with the Disable Candidate error code because both the local site address and the remote site address have been disabled as a result of bandwidth policy and cannot be used for media flow. Endpoint L, on receiving the STUN binding error response, disables all candidate pairs whose local candidates belong to the local site, including Host Candidates, Server Reflexive Candidates, or local peer-derived candidates.

Endpoint L sends a STUN binding request from its Relayed Candidate LPS-PUB-2 to R-PRIV-1, which gets dropped because R-PRIV-1 is not reachable from the public interface. Endpoint L then sends a STUN binding request from its Relayed Candidate LPS-PUB-2 to RPS-PUB-2, which Endpoint R receives from its Relayed Candidate because permissions have already been opened on RPS-PUB-2 for LPS-PUB-2. Endpoint L, on receiving the STUN binding response, validates this candidate pair. At the end of the connectivity checks timeout, Endpoint L nominates its only valid candidate pair and sends a STUN binding request with the USE-CANDIDATE attribute (as described in [IETFDRAFT-ICENAT-19] section 7.1.1.1) set. On getting the response, Endpoint L sends the final offer to the endpoint with the final candidates to be used for media flow. A sample SDP for the final offer is as follows:

 v=0
 o=- 0 0 IN IP4 10.101.0.57
 s=session
 c=IN IP4 10.101.0.57
 b=CT:99980
 t=0 0
 m=audio 52732 RTP/SAVP 114 111 112 115 116 4 8 0 97 13 118 101
 a=ice-ufrag:32sD
 a=ice-pwd:YF9/OwRcN/pXUglBv1c+5QMu
 a=candidate:1  UDP 16648703 10.101.0.57 52732 typ relay raddr 192.168.2.1 rport 50033
 a=remote-candidates:1 10.107.0.37 52714
 a=rtpmap:114 x-msrta/16000

Endpoint R, on receiving the final offer, sends the answer to the final offer. A sample SDP for the final offer is as follows:

 v=0
 o=- 0 0 IN IP4 10.107.0.37
 s=session
 c=IN IP4 10.107.0.37
 b=CT:99980
 t=0 0
 m=audio 52714 5 RTP/SAVP 114 111 112 115 116 4 8 0 97 13 118 101
 a=ice-ufrag:32sD
 a=ice-pwd:YF9/OwRcN/pXUglBv1c+5QMu
 a=candidate:1  UDP 16648703 10.107.0.37 52714 typ relay raddr 192.175.54.2 rport 50036
 a=remote-candidates:1 101.0.57 52732
 a=rtpmap:114 x-msrta/16000

Endpoint R is the bandwidth management endpoint that also sends a Bandwidth Commit message to the relay to notify the policy server that the candidates are being used for media flow. Endpoint R populates LSA with "R-PRIV-1", LRA with "RPS-PUB-2", RSA with "L-PRIV-1", and RRA with "LPS-PUB-2" because both endpoints are using their Relayed Candidates for media flow.

Endpoint R, on receiving the bandwidth admission commit response with a reservation ID from RPS, starts to send periodic bandwidth admission update requests to RPS for the duration of the media session with the reservation ID received in the commit response added to every bandwidth admission update request.