CHAPTER13 Network
Mediant 4000 SBC | User's Manual
These addresses:ports (local, STUN, TURN and any other network address) of the client are
termed "candidates". Each client sends its' candidates to the other in the SDP body of the INVITE
message. Peers then perform connectivity checks per candidate of the other peer, using STUN
binding requests sent on the RTP and RTCP ports. ICE tries each candidate and selects the one
that works (i.e., media can flow between the clients). The following figure shows a simple
illustration of ICE:
The device's support for ICE-Lite means that it does not initiate the ICE process. Instead, it
supports remote endpoints that initiate ICE to discover their workable public IP address with the
device. Therefore, the device supports the receipt of STUN binding requests for connectivity
checks of ICE candidates and responds to them with STUN responses. Note that in the response
to the INVITE message received from the remote endpoint, the device sends only a single
candidate for its' own IP address. This is the IP address of the device that the client uses. To
support ICE, the SBC leg interfacing with the ICE-enabled client (SIP entity) must be enabled for
ICE. This is done using the IP Profile parameter, IPProfile_SBCIceMode (see Configuring IP
Profiles).
As the ICE technique has been defined by the WebRTC standard as mandatory for communication
with the WebRTC client, ICE support by the device is important for deployments implementing
WebRTC. For more information on WebRTC, see WebRTC . Once a WebRTC session
(WebSocket) is established for SIP signaling between the device and the WebRTC client, the
client's IP address needs to be discovered by the SBC device using the ICE technique.
- 113 -
To Next Page
Loading...
Need help?
General
