OverviewThe SBC supports a subset of the functionality required for a full-ICE agent:- In controlling role, SBC the initiates connectivity check with a STUN Binding Request. The connectivity check by SBC the is sent in response to the first connectivity check, which is received from the peer. SBC The selects the remote Ip address for media based on the address signaled in the first STUN Binding Request, which is received from the peer. To assert the selection of media, SBC the sends STUN Binding Request with the USE-CANDIDATE attribute.
- In controlled role, SBC the initiates a single connectivity check with a STUN Binding Request to the peer. This request is sent after receiving a Binding Request from the peer, which contains the USE-CANDIDATE attribute. This behavior is important to complete the full-ICE procedures when inter-operating with WRTC peers such as Google and Chrome.
- In controlling role, SBC the protects against network loss of STUN message exchanges by introducing internal guard timers and sends STUN Keep-Alive messages at a configurable interval. This functionality is based on the procedures defined in RFC5245.
These functionalities allow SBC the to inter-operate with other ICE peers, which require the connecting peer to act as a full-ICE agent.When inter-operating with Lync endpoints, which require their own flavor of ICE, this feature extends the existing SBC implementation of ICE-Lync to support the following functionalities:- Allows specification of IPv6 candidates at Signaling and in STUN messages.
- Validates the received STUN messages and attributes based on the MS-ICE2 standards.
- Protects against network loss of STUN message exchanges by introducing internal guard timers and sends STUN Keep-Alive messages at a configurable interval.
The SBC supports the following functionalities to implement pseudo full-ICE and MS-Lync ICE:| Anchor |
|---|
| Connectivity Check Timers |
|---|
| Connectivity Check Timers |
|---|
|
TimersIn pseudo full-ICE and MS-Lync ICE configuration, SBC the determines the controlled or controlling role for a particular media stream. The role is determined based on the controlled attribute in the STUN Binding Request from the peer. SBC The runs following new timers at different stages of the STUN processing:Controlling RoleThe SBC assumes the controlling role when the controlled attribute is received in Binding Request for a media stream. In the controlling role, SBC the retrieves the remote media IP or port based on the first Binding Request from the remote end. When the Binding Request with controlled attribute is received, SBC the discontinues the phase 1 connectivity timer and sends initial Binding Request without USE-CANDIDATE. SBC The starts the phase 2 connectivity timer of 5 seconds and wait for the STUN response. Once a successful response is received from the peer to the Binding Request without USE-CANDIDATE, SBC the generates the Binding Request with USE-CANDIDATE and starts the USE-CANDIDATE check timer for 10 seconds. This timer is stopped after a successful binding response is received from the peer.Controlled RoleThe SBC assumes the controlled role when the controlling attribute is received in Binding Request for a media stream.When a STUN Binding Request with USE-CANDIDATE is received, SBC the sends back the binding response and determines the remote address for media from the received Binding Request message. In the controlled role, SBC the does not send STUN Keep-Alive. When configured as full-ICE, SBC the generates Binding Request towards the peer even when assuming the controlled role. In a controlled role, SBC the re-sends this Binding Request message (without use-candidate attribute) up to 10 times or until a successful response is received from the peer.| Note |
|---|
Binding request is generated from SBC from the only for the pseudo full-ICE support when SBC the acts as controlled agent. |
The following table describes the behavior of the timers: | Caption |
|---|
| | Timers | Applicable Role of SBC | Started | Stopped | On Expiry | Duration of the Timer (Seconds) |
|---|
| Connectivity Check phase 1 Timer | Controlled and controlling role | When full-ICE is negotiated through SDP with the peer and SBC the has either received answer or has sent answer. | When a valid Binding Request message is received from the peer, the stream is either removed or the call is disconnected. | The SBC generates an alarm sonusSbxIceTimerExpiryNotification and clears the call. | 10 | | Connectivity Check phase 2 Timer | Controlling role | When the SBC sends a Binding Request without USE-CANDIDATE attribute. | When a successful response is received to the SBC's initial Binding Request, the stream is either removed or the call is disconnected. | The SBC generates an alarm sonusSbxIceTimerExpiryNotification and clears the call. | 5 | | USE-CANDIDATE Check Timer | Controlling role | When the SBC sends a Binding Request with USE-CANDIDATE attribute. | When a successful Binding Response is received, the stream is either removed or the call is torn down. | The SBC generates an alarm sonusSbxIceTimerExpiryNotification and clears the call. | 10 | | Keep-Alive Timer | Controlling role | When ICE Keep-Alive message is first sent after receiving successful binding response to SBC's Binding Request with USE-CANDIDATE, SBC the periodically sends a STUN Keep-Alive message on RTP and RTCP ports. | When a valid Binding Request message is received from the peer, the stream is removed or the call is disconnected. | Resend Keep-Alive message. | 15 |
|
A new parameter iceKeepaliveTimer is added to Network Address Translator (NAT) Traversal of SIP Trunk Group to enable Keep-Alive timer for ICE. This parameter is supported for Keep-Alive message on RTP port in Lync mode and RTP and RTCP ports in full-ICE mode. | Note |
|---|
- Connectivity check timers are applied to both pseudo full-ICE and MS-Lync ICE support.
- In case of MS-Lync ICE, Keep-Alive messages are sent only to RTP port.
|
| Anchor |
|---|
| Re-INVITE Generation |
|---|
| Re-INVITE Generation |
|---|
|
Re-INVITE Generation Once ICE processing is completed, when SBC the is acting in the ICE controlling role, it generates a Re-INVITE specifying the local and remote candidate addresses that were selected for media. | Note |
|---|
The Re-INVITE message is generated when SBC the is configured as either iceLync or iceFull. In the case of full-ICE, the Re-INVITE message is generated only when the remote IP determined through STUN exchange is different from the original C-line IP that the endpoint sent in SDP. |
The following call flow diagram provides the pseudo ICE scenario. | Caption |
|---|
| 0 | Figure |
|---|
| 1 | Pseudo ICE Call Flow |
|---|
| 
|
| Note |
|---|
The MS Lync/Skype Remote Desktop Sharing feature is supported on the following platforms: |
|