Interface WebRtcEndpoint

All Superinterfaces:
BaseRtpEndpoint, Endpoint, KurentoObject, MediaElement, MediaObject, SdpEndpoint, SessionEndpoint
public interface WebRtcEndpoint extends BaseRtpEndpoint
Endpoint that provides bidirectional WebRTC capabilities for Kurento.

This endpoint is one side of a peer-to-peer WebRTC communication, where the other peer is either of a WebRTC capable browser (using the RTCPeerConnection API), a native WebRTC app, or even another Kurento Media Server instance.

In order to establish WebRTC communications, peers first engage in an SDP Offer/Answer negotiation process, where one of the peers (the offerer) sends an SDP Offer, while the other peer (the answerer) responds with an SDP Answer. This endpoint can work in both roles.

  • As offerer: The negotiation process is initiated by the media server.
    • Kurento generates the SDP Offer through the generateOffer() method. This offer must then be sent to the remote peer (the answerer) through the signaling channel.
    • The remote peer process the SDP Offer, and generates an SDP Answer. This answer is then sent back to the media server.
    • Upon receiving the SDP Answer, this endpoint must process it with the processAnswer() method.
  • As answerer: The negotiation process is initiated by the remote peer.
    • The remote peer, acting as offerer, generates an SDP Offer and sends it to this endpoint.
    • This endpoint processes the SDP Offer with the processOffer() method. The result of this method will be a string, containing an SDP Answer.
    • The SDP Answer must then be sent back to the offerer, so it can be processed by it.

ICE candidates and connectivity checks

SDPs are sent without ICE candidates, following the Trickle ICE optimization. Once the SDP negotiation is completed, both peers proceed with the ICE discovery process, intended to set up a bidirectional media connection. During this process, each peer...

  • Discovers ICE candidates for itself, containing pairs of IPs and ports.
  • ICE candidates are sent via the signaling channel as they are discovered, to the remote peer for probing.
  • ICE connectivity checks are run as soon as the new candidate description, from the remote peer, is available.

Once a suitable pair of candidates (one for each peer) is discovered, the media session can start. The harvesting process in Kurento, begins with the invocation of the gatherCandidates() method. Since the whole Trickle ICE purpose is to speed-up connectivity, candidates are generated asynchronously. Therefore, in order to capture the candidates, the user must subscribe to the event IceCandidateFound. It is important that the event listener is bound before invoking gatherCandidates(), otherwise a suitable candidate might be lost, and connection might not be established.

It is important to keep in mind that WebRTC connection is an asynchronous process, when designing interactions between different MediaElements. For example, it would be pointless to start recording before media is flowing. In order to be notified of state changes, the application can subscribe to events generated by the WebRtcEndpoint. Following is a full list of events generated by WebRtcEndpoint:

  • IceComponentStateChanged: This event informs only about changes in the ICE connection state. Possible values are:
    • DISCONNECTED: No activity scheduled
    • GATHERING: Gathering local candidates
    • CONNECTING: Establishing connectivity
    • CONNECTED: At least one working candidate pair
    • READY: ICE concluded, candidate pair selection is now final
    • FAILED: Connectivity checks have been completed, but media connection was not established
    The transitions between states are covered in RFC5245. It could be said that it is network-only, as it only takes into account the state of the network connection, ignoring other higher level stuff, like DTLS handshake, RTCP flow, etc. This implies that, while the component state is CONNECTED, there might be no media flowing between the peers. This makes this event useful only to receive low-level information about the connection between peers. Even more, while other events might leave a graceful period of time before firing, this event fires immediately after the state change is detected.
  • IceCandidateFound: Raised when a new candidate is discovered. ICE candidates must be sent to the remote peer of the connection. Failing to do so for some or all of the candidates might render the connection unusable.
  • IceGatheringDone: Raised when the ICE gathering process is completed. This means that all candidates have already been discovered.
  • NewCandidatePairSelected: Raised when a new ICE candidate pair gets selected. The pair contains both local and remote candidates being used for a component. This event can be raised during a media session, if a new pair of candidates with higher priority in the link are found.
  • DataChannelOpened: Raised when a data channel is open.
  • DataChannelClosed: Raised when a data channel is closed.

Registering to any of above events requires the application to provide a callback function. Each event provides different information, so it is recommended to consult the signature of the event listeners.

Bitrate management and network congestion control

Congestion control is one of the most important features of WebRTC. WebRTC connections start with the lowest bandwidth configured and slowly ramps up to the maximum available bandwidth, or to the higher limit of the allowed range in case no bandwidth limitation is detected.

Notice that WebRtcEndpoints in Kurento are designed in a way that multiple WebRTC connections fed by the same stream, share the same bitrate limits. When a new connection is added, as it requires to start with low bandwidth, it will cause the rest of connections to experience a transient period of degraded quality, until it stabilizes its bitrate. This doesn't apply when transcoding is involved; transcoders will adjust their output bitrate based in the receiver requirements, but it won't affect the original stream.

If an incoming WebRTC stream needs to be transcoded, for whatever reason, all WebRtcEndpoints fed from the transcoder output will share a separate quality than the ones connected directly to the original stream.

Note that the default MaxVideoSendBandwidth is a VERY conservative value, and leads to a low maximum video quality. Most applications will probably want to increase this to higher values such as 2000 kbps (2 Mbps). Check the documentation of BaseRtpEndpoint and :rom:cls:`RembParams` for detailed information about bitrate management.

Keyframe requests (PLI/FIR)

WebRTC allows receivers to emit keyframe requests for the senders, by means of RTCP Feedback messages called PLI (Picture Loss Indication) and/or FIR (Full Intra-frame Request). Kurento supports this mechanism: PLI and FIR requests that are emitted by a receiver will be forwarded to the sender. This way, the encoder of the video (e.g. a web browser) can decide if a new keyframe should be generated. Sometimes Kurento itself acts as encoder when transcoding is enabled, so in this case it is Kurento itself the one generating keyframes.

On top of this, a common technique used for streaming is to forcefully request new keyframes. Either in fixed intervals, or explicitly by the application. Kurento doesn't support the former, but the latter is possible by calling requestKeyframe() from a subscribing element (i.e. an endpoint that sends data out from the Kurento Pipeline).

WebRTC Data Channels

DataChannels allow other media elements that make use of the DataPad, to send arbitrary data. For instance, if there is a filter that publishes event information, it will be sent to the remote peer through the channel. There is no API available for programmers to make use of this feature in the WebRtcElement. DataChannels can be configured to provide the following:

  • Reliable or partially reliable delivery of sent messages
  • In-order or out-of-order delivery of sent messages

Unreliable, out-of-order delivery is equivalent to raw UDP semantics. The message may make it, or it may not, and order is not important. However, the channel can be configured to be partially reliable by specifying the maximum number of retransmissions or setting a time limit for retransmissions: the WebRTC stack will handle the acknowledgments and timeouts.

The possibility to create DataChannels in a WebRtcEndpoint must be explicitly enabled when creating the endpoint, as this feature is disabled by default. If this is the case, they can be created invoking the createDataChannel method. The arguments for this method, all of them optional, provide the necessary configuration:

  • label: assigns a label to the DataChannel. This can help identify each possible channel separately.
  • ordered: specifies if the DataChannel guarantees order, which is the default mode. If maxPacketLifetime and maxRetransmits have not been set, this enables reliable mode.
  • maxPacketLifeTime: The time window in milliseconds, during which transmissions and retransmissions may take place in unreliable mode. This forces unreliable mode, even if ordered has been activated.
  • maxRetransmits: maximum number of retransmissions that are attempted in unreliable mode. This forces unreliable mode, even if ordered has been activated.
  • Protocol: Name of the subprotocol used for data communication.

  • Method Details

    • getNetworkInterfaces

      String getNetworkInterfaces()
      Get Local network interfaces used for ICE gathering.

      If you know which network interfaces should be used to perform ICE (for WebRTC connectivity), you can define them here. Doing so has several advantages:

      • The WebRTC ICE gathering process will be much quicker. Normally, it needs to gather local candidates for all of the network interfaces, but this step can be made faster if you limit it to only the interface that you know will work.
      • It will ensure that the media server always decides to use the correct network interface. With WebRTC ICE gathering it's possible that, under some circumstances (in systems with virtual network interfaces such as docker0) the ICE process ends up choosing the wrong local IP.

      networkInterfaces is a comma-separated list of network interface names.

      Examples:

      • networkInterfaces=eth0
      • networkInterfaces=eth0,enp0s25

    • getNetworkInterfaces

      void getNetworkInterfaces(Continuation<String> cont)
      Get Local network interfaces used for ICE gathering.

      If you know which network interfaces should be used to perform ICE (for WebRTC connectivity), you can define them here. Doing so has several advantages:

      • The WebRTC ICE gathering process will be much quicker. Normally, it needs to gather local candidates for all of the network interfaces, but this step can be made faster if you limit it to only the interface that you know will work.
      • It will ensure that the media server always decides to use the correct network interface. With WebRTC ICE gathering it's possible that, under some circumstances (in systems with virtual network interfaces such as docker0) the ICE process ends up choosing the wrong local IP.

      networkInterfaces is a comma-separated list of network interface names.

      Examples:

      • networkInterfaces=eth0
      • networkInterfaces=eth0,enp0s25

    • getNetworkInterfaces

      TFuture<String> getNetworkInterfaces(Transaction tx)
      Get Local network interfaces used for ICE gathering.

      If you know which network interfaces should be used to perform ICE (for WebRTC connectivity), you can define them here. Doing so has several advantages:

      • The WebRTC ICE gathering process will be much quicker. Normally, it needs to gather local candidates for all of the network interfaces, but this step can be made faster if you limit it to only the interface that you know will work.
      • It will ensure that the media server always decides to use the correct network interface. With WebRTC ICE gathering it's possible that, under some circumstances (in systems with virtual network interfaces such as docker0) the ICE process ends up choosing the wrong local IP.

      networkInterfaces is a comma-separated list of network interface names.

      Examples:

      • networkInterfaces=eth0
      • networkInterfaces=eth0,enp0s25

    • setNetworkInterfaces

      void setNetworkInterfaces(String networkInterfaces)
      Set Local network interfaces used for ICE gathering.

      If you know which network interfaces should be used to perform ICE (for WebRTC connectivity), you can define them here. Doing so has several advantages:

      • The WebRTC ICE gathering process will be much quicker. Normally, it needs to gather local candidates for all of the network interfaces, but this step can be made faster if you limit it to only the interface that you know will work.
      • It will ensure that the media server always decides to use the correct network interface. With WebRTC ICE gathering it's possible that, under some circumstances (in systems with virtual network interfaces such as docker0) the ICE process ends up choosing the wrong local IP.

      networkInterfaces is a comma-separated list of network interface names.

      Examples:

      • networkInterfaces=eth0
      • networkInterfaces=eth0,enp0s25

    • setNetworkInterfaces

      void setNetworkInterfaces(String networkInterfaces, Continuation<Void> cont)
      Set Local network interfaces used for ICE gathering.

      If you know which network interfaces should be used to perform ICE (for WebRTC connectivity), you can define them here. Doing so has several advantages:

      • The WebRTC ICE gathering process will be much quicker. Normally, it needs to gather local candidates for all of the network interfaces, but this step can be made faster if you limit it to only the interface that you know will work.
      • It will ensure that the media server always decides to use the correct network interface. With WebRTC ICE gathering it's possible that, under some circumstances (in systems with virtual network interfaces such as docker0) the ICE process ends up choosing the wrong local IP.

      networkInterfaces is a comma-separated list of network interface names.

      Examples:

      • networkInterfaces=eth0
      • networkInterfaces=eth0,enp0s25

    • setNetworkInterfaces

      void setNetworkInterfaces(String networkInterfaces, Transaction tx)
      Set Local network interfaces used for ICE gathering.

      If you know which network interfaces should be used to perform ICE (for WebRTC connectivity), you can define them here. Doing so has several advantages:

      • The WebRTC ICE gathering process will be much quicker. Normally, it needs to gather local candidates for all of the network interfaces, but this step can be made faster if you limit it to only the interface that you know will work.
      • It will ensure that the media server always decides to use the correct network interface. With WebRTC ICE gathering it's possible that, under some circumstances (in systems with virtual network interfaces such as docker0) the ICE process ends up choosing the wrong local IP.

      networkInterfaces is a comma-separated list of network interface names.

      Examples:

      • networkInterfaces=eth0
      • networkInterfaces=eth0,enp0s25

    • getIceTcp

      boolean getIceTcp()
      Get Enable ICE-TCP candidate gathering.

      This setting enables or disables using TCP for ICE candidate gathering in the underlying libnice library: https://libnice.freedesktop.org/libnice/NiceAgent.html#NiceAgent--ice-tcp

      You might want to disable ICE-TCP to potentially speed up ICE gathering by avoiding TCP candidates in scenarios where they are not needed.

      iceTcp is either 1 (ON) or 0 (OFF). Default: 1 (ON).

    • getIceTcp

      void getIceTcp(Continuation<Boolean> cont)
      Get Enable ICE-TCP candidate gathering.

      This setting enables or disables using TCP for ICE candidate gathering in the underlying libnice library: https://libnice.freedesktop.org/libnice/NiceAgent.html#NiceAgent--ice-tcp

      You might want to disable ICE-TCP to potentially speed up ICE gathering by avoiding TCP candidates in scenarios where they are not needed.

      iceTcp is either 1 (ON) or 0 (OFF). Default: 1 (ON).

    • getIceTcp

      TFuture<Boolean> getIceTcp(Transaction tx)
      Get Enable ICE-TCP candidate gathering.

      This setting enables or disables using TCP for ICE candidate gathering in the underlying libnice library: https://libnice.freedesktop.org/libnice/NiceAgent.html#NiceAgent--ice-tcp

      You might want to disable ICE-TCP to potentially speed up ICE gathering by avoiding TCP candidates in scenarios where they are not needed.

      iceTcp is either 1 (ON) or 0 (OFF). Default: 1 (ON).

    • setIceTcp

      void setIceTcp(boolean iceTcp)
      Set Enable ICE-TCP candidate gathering.

      This setting enables or disables using TCP for ICE candidate gathering in the underlying libnice library: https://libnice.freedesktop.org/libnice/NiceAgent.html#NiceAgent--ice-tcp

      You might want to disable ICE-TCP to potentially speed up ICE gathering by avoiding TCP candidates in scenarios where they are not needed.

      iceTcp is either 1 (ON) or 0 (OFF). Default: 1 (ON).

    • setIceTcp

      void setIceTcp(boolean iceTcp, Continuation<Void> cont)
      Set Enable ICE-TCP candidate gathering.

      This setting enables or disables using TCP for ICE candidate gathering in the underlying libnice library: https://libnice.freedesktop.org/libnice/NiceAgent.html#NiceAgent--ice-tcp

      You might want to disable ICE-TCP to potentially speed up ICE gathering by avoiding TCP candidates in scenarios where they are not needed.

      iceTcp is either 1 (ON) or 0 (OFF). Default: 1 (ON).

    • setIceTcp

      void setIceTcp(boolean iceTcp, Transaction tx)
      Set Enable ICE-TCP candidate gathering.

      This setting enables or disables using TCP for ICE candidate gathering in the underlying libnice library: https://libnice.freedesktop.org/libnice/NiceAgent.html#NiceAgent--ice-tcp

      You might want to disable ICE-TCP to potentially speed up ICE gathering by avoiding TCP candidates in scenarios where they are not needed.

      iceTcp is either 1 (ON) or 0 (OFF). Default: 1 (ON).

    • getStunServerAddress

      String getStunServerAddress()
      Get STUN server IP address.

      The ICE process uses STUN to punch holes through NAT firewalls.

      stunServerAddress MUST be an IP address; domain names are NOT supported.

      You need to use a well-working STUN server. Use this to check if it works:
      https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
      From that check, you should get at least one Server-Reflexive Candidate (type srflx).

    • getStunServerAddress

      void getStunServerAddress(Continuation<String> cont)
      Get STUN server IP address.

      The ICE process uses STUN to punch holes through NAT firewalls.

      stunServerAddress MUST be an IP address; domain names are NOT supported.

      You need to use a well-working STUN server. Use this to check if it works:
      https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
      From that check, you should get at least one Server-Reflexive Candidate (type srflx).

    • getStunServerAddress

      TFuture<String> getStunServerAddress(Transaction tx)
      Get STUN server IP address.

      The ICE process uses STUN to punch holes through NAT firewalls.

      stunServerAddress MUST be an IP address; domain names are NOT supported.

      You need to use a well-working STUN server. Use this to check if it works:
      https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
      From that check, you should get at least one Server-Reflexive Candidate (type srflx).

    • setStunServerAddress

      void setStunServerAddress(String stunServerAddress)
      Set STUN server IP address.

      The ICE process uses STUN to punch holes through NAT firewalls.

      stunServerAddress MUST be an IP address; domain names are NOT supported.

      You need to use a well-working STUN server. Use this to check if it works:
      https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
      From that check, you should get at least one Server-Reflexive Candidate (type srflx).

    • setStunServerAddress

      void setStunServerAddress(String stunServerAddress, Continuation<Void> cont)
      Set STUN server IP address.

      The ICE process uses STUN to punch holes through NAT firewalls.

      stunServerAddress MUST be an IP address; domain names are NOT supported.

      You need to use a well-working STUN server. Use this to check if it works:
      https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
      From that check, you should get at least one Server-Reflexive Candidate (type srflx).

    • setStunServerAddress

      void setStunServerAddress(String stunServerAddress, Transaction tx)
      Set STUN server IP address.

      The ICE process uses STUN to punch holes through NAT firewalls.

      stunServerAddress MUST be an IP address; domain names are NOT supported.

      You need to use a well-working STUN server. Use this to check if it works:
      https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
      From that check, you should get at least one Server-Reflexive Candidate (type srflx).

    • getStunServerPort

      int getStunServerPort()
      Get Port of the STUN server

    • getStunServerPort

      void getStunServerPort(Continuation<Integer> cont)
      Get Port of the STUN server

    • getStunServerPort

      TFuture<Integer> getStunServerPort(Transaction tx)
      Get Port of the STUN server

    • setStunServerPort

      void setStunServerPort(int stunServerPort)
      Set Port of the STUN server

    • setStunServerPort

      void setStunServerPort(int stunServerPort, Continuation<Void> cont)
      Set Port of the STUN server

    • setStunServerPort

      void setStunServerPort(int stunServerPort, Transaction tx)
      Set Port of the STUN server

    • getTurnUrl

      String getTurnUrl()
      Get TURN server URL.

      When STUN is not enough to open connections through some NAT firewalls, using TURN is the remaining alternative.

      Note that TURN is a superset of STUN, so you don't need to configure STUN if you are using TURN.

      The provided URL should follow one of these formats:

      • user:password@ipaddress:port
      • user:password@ipaddress:port?transport=[udp|tcp|tls]

      ipaddress MUST be an IP address; domain names are NOT supported.
      transport is OPTIONAL. Possible values: udp, tcp, tls. Default: udp.

      You need to use a well-working TURN server. Use this to check if it works:
      https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
      From that check, you should get at least one Server-Reflexive Candidate (type srflx) AND one Relay Candidate (type relay).

    • getTurnUrl

      void getTurnUrl(Continuation<String> cont)
      Get TURN server URL.

      When STUN is not enough to open connections through some NAT firewalls, using TURN is the remaining alternative.

      Note that TURN is a superset of STUN, so you don't need to configure STUN if you are using TURN.

      The provided URL should follow one of these formats:

      • user:password@ipaddress:port
      • user:password@ipaddress:port?transport=[udp|tcp|tls]

      ipaddress MUST be an IP address; domain names are NOT supported.
      transport is OPTIONAL. Possible values: udp, tcp, tls. Default: udp.

      You need to use a well-working TURN server. Use this to check if it works:
      https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
      From that check, you should get at least one Server-Reflexive Candidate (type srflx) AND one Relay Candidate (type relay).

    • getTurnUrl

      TFuture<String> getTurnUrl(Transaction tx)
      Get TURN server URL.

      When STUN is not enough to open connections through some NAT firewalls, using TURN is the remaining alternative.

      Note that TURN is a superset of STUN, so you don't need to configure STUN if you are using TURN.

      The provided URL should follow one of these formats:

      • user:password@ipaddress:port
      • user:password@ipaddress:port?transport=[udp|tcp|tls]

      ipaddress MUST be an IP address; domain names are NOT supported.
      transport is OPTIONAL. Possible values: udp, tcp, tls. Default: udp.

      You need to use a well-working TURN server. Use this to check if it works:
      https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
      From that check, you should get at least one Server-Reflexive Candidate (type srflx) AND one Relay Candidate (type relay).

    • setTurnUrl

      void setTurnUrl(String turnUrl)
      Set TURN server URL.

      When STUN is not enough to open connections through some NAT firewalls, using TURN is the remaining alternative.

      Note that TURN is a superset of STUN, so you don't need to configure STUN if you are using TURN.

      The provided URL should follow one of these formats:

      • user:password@ipaddress:port
      • user:password@ipaddress:port?transport=[udp|tcp|tls]

      ipaddress MUST be an IP address; domain names are NOT supported.
      transport is OPTIONAL. Possible values: udp, tcp, tls. Default: udp.

      You need to use a well-working TURN server. Use this to check if it works:
      https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
      From that check, you should get at least one Server-Reflexive Candidate (type srflx) AND one Relay Candidate (type relay).

    • setTurnUrl

      void setTurnUrl(String turnUrl, Continuation<Void> cont)
      Set TURN server URL.

      When STUN is not enough to open connections through some NAT firewalls, using TURN is the remaining alternative.

      Note that TURN is a superset of STUN, so you don't need to configure STUN if you are using TURN.

      The provided URL should follow one of these formats:

      • user:password@ipaddress:port
      • user:password@ipaddress:port?transport=[udp|tcp|tls]

      ipaddress MUST be an IP address; domain names are NOT supported.
      transport is OPTIONAL. Possible values: udp, tcp, tls. Default: udp.

      You need to use a well-working TURN server. Use this to check if it works:
      https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
      From that check, you should get at least one Server-Reflexive Candidate (type srflx) AND one Relay Candidate (type relay).

    • setTurnUrl

      void setTurnUrl(String turnUrl, Transaction tx)
      Set TURN server URL.

      When STUN is not enough to open connections through some NAT firewalls, using TURN is the remaining alternative.

      Note that TURN is a superset of STUN, so you don't need to configure STUN if you are using TURN.

      The provided URL should follow one of these formats:

      • user:password@ipaddress:port
      • user:password@ipaddress:port?transport=[udp|tcp|tls]

      ipaddress MUST be an IP address; domain names are NOT supported.
      transport is OPTIONAL. Possible values: udp, tcp, tls. Default: udp.

      You need to use a well-working TURN server. Use this to check if it works:
      https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
      From that check, you should get at least one Server-Reflexive Candidate (type srflx) AND one Relay Candidate (type relay).

    • getExternalIPv4

      String getExternalIPv4()
      Get External IPv4 address of the media server.

      Forces all local IPv4 ICE candidates to have the given address. This is really nothing more than a hack, but it's very effective to force a public IP address when one is known in advance for the media server. In doing so, KMS will not need a STUN or TURN server, but remote peers will still be able to contact it.

      You can try using this setting if KMS is deployed on a publicly accessible server, without NAT, and with a static public IP address. But if it doesn't work for you, just go back to configuring a STUN or TURN server for ICE.

      Only set this parameter if you know what you're doing, and you understand 100% WHY you need it. For the majority of cases, you should just prefer to configure a STUN or TURN server.

      externalIPv4 is a single IPv4 address.

      Example:

      • externalIPv4=198.51.100.1

    • getExternalIPv4

      void getExternalIPv4(Continuation<String> cont)
      Get External IPv4 address of the media server.

      Forces all local IPv4 ICE candidates to have the given address. This is really nothing more than a hack, but it's very effective to force a public IP address when one is known in advance for the media server. In doing so, KMS will not need a STUN or TURN server, but remote peers will still be able to contact it.

      You can try using this setting if KMS is deployed on a publicly accessible server, without NAT, and with a static public IP address. But if it doesn't work for you, just go back to configuring a STUN or TURN server for ICE.

      Only set this parameter if you know what you're doing, and you understand 100% WHY you need it. For the majority of cases, you should just prefer to configure a STUN or TURN server.

      externalIPv4 is a single IPv4 address.

      Example:

      • externalIPv4=198.51.100.1

    • getExternalIPv4

      TFuture<String> getExternalIPv4(Transaction tx)
      Get External IPv4 address of the media server.

      Forces all local IPv4 ICE candidates to have the given address. This is really nothing more than a hack, but it's very effective to force a public IP address when one is known in advance for the media server. In doing so, KMS will not need a STUN or TURN server, but remote peers will still be able to contact it.

      You can try using this setting if KMS is deployed on a publicly accessible server, without NAT, and with a static public IP address. But if it doesn't work for you, just go back to configuring a STUN or TURN server for ICE.

      Only set this parameter if you know what you're doing, and you understand 100% WHY you need it. For the majority of cases, you should just prefer to configure a STUN or TURN server.

      externalIPv4 is a single IPv4 address.

      Example:

      • externalIPv4=198.51.100.1

    • setExternalIPv4

      void setExternalIPv4(String externalIPv4)
      Set External IPv4 address of the media server.

      Forces all local IPv4 ICE candidates to have the given address. This is really nothing more than a hack, but it's very effective to force a public IP address when one is known in advance for the media server. In doing so, KMS will not need a STUN or TURN server, but remote peers will still be able to contact it.

      You can try using this setting if KMS is deployed on a publicly accessible server, without NAT, and with a static public IP address. But if it doesn't work for you, just go back to configuring a STUN or TURN server for ICE.

      Only set this parameter if you know what you're doing, and you understand 100% WHY you need it. For the majority of cases, you should just prefer to configure a STUN or TURN server.

      externalIPv4 is a single IPv4 address.

      Example:

      • externalIPv4=198.51.100.1

    • setExternalIPv4

      void setExternalIPv4(String externalIPv4, Continuation<Void> cont)
      Set External IPv4 address of the media server.

      Forces all local IPv4 ICE candidates to have the given address. This is really nothing more than a hack, but it's very effective to force a public IP address when one is known in advance for the media server. In doing so, KMS will not need a STUN or TURN server, but remote peers will still be able to contact it.

      You can try using this setting if KMS is deployed on a publicly accessible server, without NAT, and with a static public IP address. But if it doesn't work for you, just go back to configuring a STUN or TURN server for ICE.

      Only set this parameter if you know what you're doing, and you understand 100% WHY you need it. For the majority of cases, you should just prefer to configure a STUN or TURN server.

      externalIPv4 is a single IPv4 address.

      Example:

      • externalIPv4=198.51.100.1

    • setExternalIPv4

      void setExternalIPv4(String externalIPv4, Transaction tx)
      Set External IPv4 address of the media server.

      Forces all local IPv4 ICE candidates to have the given address. This is really nothing more than a hack, but it's very effective to force a public IP address when one is known in advance for the media server. In doing so, KMS will not need a STUN or TURN server, but remote peers will still be able to contact it.

      You can try using this setting if KMS is deployed on a publicly accessible server, without NAT, and with a static public IP address. But if it doesn't work for you, just go back to configuring a STUN or TURN server for ICE.

      Only set this parameter if you know what you're doing, and you understand 100% WHY you need it. For the majority of cases, you should just prefer to configure a STUN or TURN server.

      externalIPv4 is a single IPv4 address.

      Example:

      • externalIPv4=198.51.100.1

    • getExternalIPv6

      String getExternalIPv6()
      Get External IPv6 address of the media server.

      Forces all local IPv6 ICE candidates to have the given address. This is really nothing more than a hack, but it's very effective to force a public IP address when one is known in advance for the media server. In doing so, KMS will not need a STUN or TURN server, but remote peers will still be able to contact it.

      You can try using this setting if KMS is deployed on a publicly accessible server, without NAT, and with a static public IP address. But if it doesn't work for you, just go back to configuring a STUN or TURN server for ICE.

      Only set this parameter if you know what you're doing, and you understand 100% WHY you need it. For the majority of cases, you should just prefer to configure a STUN or TURN server.

      externalIPv6 is a single IPv6 address.

      Example:

      • externalIPv6=2001:0db8:85a3:0000:0000:8a2e:0370:7334

    • getExternalIPv6

      void getExternalIPv6(Continuation<String> cont)
      Get External IPv6 address of the media server.

      Forces all local IPv6 ICE candidates to have the given address. This is really nothing more than a hack, but it's very effective to force a public IP address when one is known in advance for the media server. In doing so, KMS will not need a STUN or TURN server, but remote peers will still be able to contact it.

      You can try using this setting if KMS is deployed on a publicly accessible server, without NAT, and with a static public IP address. But if it doesn't work for you, just go back to configuring a STUN or TURN server for ICE.

      Only set this parameter if you know what you're doing, and you understand 100% WHY you need it. For the majority of cases, you should just prefer to configure a STUN or TURN server.

      externalIPv6 is a single IPv6 address.

      Example:

      • externalIPv6=2001:0db8:85a3:0000:0000:8a2e:0370:7334

    • getExternalIPv6

      TFuture<String> getExternalIPv6(Transaction tx)
      Get External IPv6 address of the media server.

      Forces all local IPv6 ICE candidates to have the given address. This is really nothing more than a hack, but it's very effective to force a public IP address when one is known in advance for the media server. In doing so, KMS will not need a STUN or TURN server, but remote peers will still be able to contact it.

      You can try using this setting if KMS is deployed on a publicly accessible server, without NAT, and with a static public IP address. But if it doesn't work for you, just go back to configuring a STUN or TURN server for ICE.

      Only set this parameter if you know what you're doing, and you understand 100% WHY you need it. For the majority of cases, you should just prefer to configure a STUN or TURN server.

      externalIPv6 is a single IPv6 address.

      Example:

      • externalIPv6=2001:0db8:85a3:0000:0000:8a2e:0370:7334

    • setExternalIPv6

      void setExternalIPv6(String externalIPv6)
      Set External IPv6 address of the media server.

      Forces all local IPv6 ICE candidates to have the given address. This is really nothing more than a hack, but it's very effective to force a public IP address when one is known in advance for the media server. In doing so, KMS will not need a STUN or TURN server, but remote peers will still be able to contact it.

      You can try using this setting if KMS is deployed on a publicly accessible server, without NAT, and with a static public IP address. But if it doesn't work for you, just go back to configuring a STUN or TURN server for ICE.

      Only set this parameter if you know what you're doing, and you understand 100% WHY you need it. For the majority of cases, you should just prefer to configure a STUN or TURN server.

      externalIPv6 is a single IPv6 address.

      Example:

      • externalIPv6=2001:0db8:85a3:0000:0000:8a2e:0370:7334

    • setExternalIPv6

      void setExternalIPv6(String externalIPv6, Continuation<Void> cont)
      Set External IPv6 address of the media server.

      Forces all local IPv6 ICE candidates to have the given address. This is really nothing more than a hack, but it's very effective to force a public IP address when one is known in advance for the media server. In doing so, KMS will not need a STUN or TURN server, but remote peers will still be able to contact it.

      You can try using this setting if KMS is deployed on a publicly accessible server, without NAT, and with a static public IP address. But if it doesn't work for you, just go back to configuring a STUN or TURN server for ICE.

      Only set this parameter if you know what you're doing, and you understand 100% WHY you need it. For the majority of cases, you should just prefer to configure a STUN or TURN server.

      externalIPv6 is a single IPv6 address.

      Example:

      • externalIPv6=2001:0db8:85a3:0000:0000:8a2e:0370:7334

    • setExternalIPv6

      void setExternalIPv6(String externalIPv6, Transaction tx)
      Set External IPv6 address of the media server.

      Forces all local IPv6 ICE candidates to have the given address. This is really nothing more than a hack, but it's very effective to force a public IP address when one is known in advance for the media server. In doing so, KMS will not need a STUN or TURN server, but remote peers will still be able to contact it.

      You can try using this setting if KMS is deployed on a publicly accessible server, without NAT, and with a static public IP address. But if it doesn't work for you, just go back to configuring a STUN or TURN server for ICE.

      Only set this parameter if you know what you're doing, and you understand 100% WHY you need it. For the majority of cases, you should just prefer to configure a STUN or TURN server.

      externalIPv6 is a single IPv6 address.

      Example:

      • externalIPv6=2001:0db8:85a3:0000:0000:8a2e:0370:7334

    • getICECandidatePairs

      List<IceCandidatePair> getICECandidatePairs()
      Get the ICE candidate pair (local and remote candidates) used by the ICE library for each stream.

    • getICECandidatePairs

      void getICECandidatePairs(Continuation<List<IceCandidatePair>> cont)
      Get the ICE candidate pair (local and remote candidates) used by the ICE library for each stream.

    • getICECandidatePairs

      TFuture<List<IceCandidatePair>> getICECandidatePairs(Transaction tx)
      Get the ICE candidate pair (local and remote candidates) used by the ICE library for each stream.

    • getIceConnectionState

      List<IceConnection> getIceConnectionState()
      Get the ICE connection state for all the connections.

    • getIceConnectionState

      void getIceConnectionState(Continuation<List<IceConnection>> cont)
      Get the ICE connection state for all the connections.

    • getIceConnectionState

      TFuture<List<IceConnection>> getIceConnectionState(Transaction tx)
      Get the ICE connection state for all the connections.

    • getDtlsConnectionState

      List<DtlsConnection> getDtlsConnectionState()
      Get the DTLS connection state for all the connections.

    • getDtlsConnectionState

      void getDtlsConnectionState(Continuation<List<DtlsConnection>> cont)
      Get the DTLS connection state for all the connections.

    • getDtlsConnectionState

      TFuture<List<DtlsConnection>> getDtlsConnectionState(Transaction tx)
      Get the DTLS connection state for all the connections.

    • gatherCandidates

      void gatherCandidates()
      Start the ICE candidate gathering.

      This method triggers the asynchronous discovery of ICE candidates (as per the Trickle ICE mechanism), and returns immediately. Every newly trickled candidate is reported to the application by means of an IceCandidateFound event. Finally, when all candidates have been gathered, the IceGatheringDone event is emitted.

      Normally, you would call this method as soon as possible after calling SdpEndpoint::generateOffer or SdpEndpoint::processOffer, to quickly start discovering candidates and sending them to the remote peer.

      You can also call this method before calling generateOffer or processOffer. Doing so will include any already gathered candidates into the resulting SDP. You can leverage this behavior to implement fully traditional ICE (without Trickle): first call gatherCandidates, then only handle the SDP messages after the IceGatheringDone event has been received. This way, you're making sure that all candidates have indeed been gathered, so the resulting SDP will include all of them.

    • gatherCandidates

      void gatherCandidates(Continuation<Void> cont)
      Asynchronous version of gatherCandidates: Continuation.onSuccess(F) is called when the action is done. If an error occurs, Continuation.onError(Throwable) is called.
      See Also:

    • gatherCandidates

      void gatherCandidates(Transaction tx)
      Start the ICE candidate gathering.

      This method triggers the asynchronous discovery of ICE candidates (as per the Trickle ICE mechanism), and returns immediately. Every newly trickled candidate is reported to the application by means of an IceCandidateFound event. Finally, when all candidates have been gathered, the IceGatheringDone event is emitted.

      Normally, you would call this method as soon as possible after calling SdpEndpoint::generateOffer or SdpEndpoint::processOffer, to quickly start discovering candidates and sending them to the remote peer.

      You can also call this method before calling generateOffer or processOffer. Doing so will include any already gathered candidates into the resulting SDP. You can leverage this behavior to implement fully traditional ICE (without Trickle): first call gatherCandidates, then only handle the SDP messages after the IceGatheringDone event has been received. This way, you're making sure that all candidates have indeed been gathered, so the resulting SDP will include all of them.

    • addIceCandidate

      void addIceCandidate(IceCandidate candidate)
      Process an ICE candidate sent by the remote peer of the connection.
      Parameters:
      candidate - Remote ICE candidate

    • addIceCandidate

      void addIceCandidate(IceCandidate candidate, Continuation<Void> cont)
      Asynchronous version of addIceCandidate: Continuation.onSuccess(F) is called when the action is done. If an error occurs, Continuation.onError(Throwable) is called.
      Parameters:
      candidate - Remote ICE candidate
      See Also:

    • addIceCandidate

      void addIceCandidate(Transaction tx, IceCandidate candidate)
      Process an ICE candidate sent by the remote peer of the connection.
      Parameters:
      candidate - Remote ICE candidate

    • createDataChannel

      void createDataChannel(String label, boolean ordered, int maxPacketLifeTime, int maxRetransmits, String protocol)
      Create a new data channel, if data channels are supported.

      Being supported means that the WebRtcEndpoint has been created with data channel support, the client also supports data channels, and they have been negotiated in the SDP exchange. Otherwise, the method throws an exception, indicating that the operation is not possible.

      Data channels can work in either unreliable mode (analogous to User Datagram Protocol or UDP) or reliable mode (analogous to Transmission Control Protocol or TCP). The two modes have a simple distinction:

      • Reliable mode guarantees the transmission of messages and also the order in which they are delivered. This takes extra overhead, thus potentially making this mode slower.
      • Unreliable mode does not guarantee every message will get to the other side nor what order they get there. This removes the overhead, allowing this mode to work much faster.

      If data channels are not supported, this method throws an exception.

      Parameters:
      label - Channel's label
      ordered - If the data channel should guarantee order or not. If true, and maxPacketLifeTime and maxRetransmits have not been provided, reliable mode is activated.
      maxPacketLifeTime - The time window (in milliseconds) during which transmissions and retransmissions may take place in unreliable mode. Note that this forces unreliable mode, even if ordered has been activated.
      maxRetransmits - maximum number of retransmissions that are attempted in unreliable mode. Note that this forces unreliable mode, even if ordered has been activated.
      protocol - Name of the subprotocol used for data communication

    • createDataChannel

      void createDataChannel(String label, boolean ordered, int maxPacketLifeTime, int maxRetransmits, String protocol, Continuation<Void> cont)
      Asynchronous version of createDataChannel: Continuation.onSuccess(F) is called when the action is done. If an error occurs, Continuation.onError(Throwable) is called.
      Parameters:
      label - Channel's label
      ordered - If the data channel should guarantee order or not. If true, and maxPacketLifeTime and maxRetransmits have not been provided, reliable mode is activated.
      maxPacketLifeTime - The time window (in milliseconds) during which transmissions and retransmissions may take place in unreliable mode. Note that this forces unreliable mode, even if ordered has been activated.
      maxRetransmits - maximum number of retransmissions that are attempted in unreliable mode. Note that this forces unreliable mode, even if ordered has been activated.
      protocol - Name of the subprotocol used for data communication
      See Also:

    • createDataChannel

      void createDataChannel(Transaction tx, String label, boolean ordered, int maxPacketLifeTime, int maxRetransmits, String protocol)
      Create a new data channel, if data channels are supported.

      Being supported means that the WebRtcEndpoint has been created with data channel support, the client also supports data channels, and they have been negotiated in the SDP exchange. Otherwise, the method throws an exception, indicating that the operation is not possible.

      Data channels can work in either unreliable mode (analogous to User Datagram Protocol or UDP) or reliable mode (analogous to Transmission Control Protocol or TCP). The two modes have a simple distinction:

      • Reliable mode guarantees the transmission of messages and also the order in which they are delivered. This takes extra overhead, thus potentially making this mode slower.
      • Unreliable mode does not guarantee every message will get to the other side nor what order they get there. This removes the overhead, allowing this mode to work much faster.

      If data channels are not supported, this method throws an exception.

      Parameters:
      label - Channel's label
      ordered - If the data channel should guarantee order or not. If true, and maxPacketLifeTime and maxRetransmits have not been provided, reliable mode is activated.
      maxPacketLifeTime - The time window (in milliseconds) during which transmissions and retransmissions may take place in unreliable mode. Note that this forces unreliable mode, even if ordered has been activated.
      maxRetransmits - maximum number of retransmissions that are attempted in unreliable mode. Note that this forces unreliable mode, even if ordered has been activated.
      protocol - Name of the subprotocol used for data communication

    • closeDataChannel

      void closeDataChannel(int channelId)
      Closes an open data channel
      Parameters:
      channelId - The channel identifier

    • closeDataChannel

      void closeDataChannel(int channelId, Continuation<Void> cont)
      Asynchronous version of closeDataChannel: Continuation.onSuccess(F) is called when the action is done. If an error occurs, Continuation.onError(Throwable) is called.
      Parameters:
      channelId - The channel identifier
      See Also:

    • closeDataChannel

      void closeDataChannel(Transaction tx, int channelId)
      Closes an open data channel
      Parameters:
      channelId - The channel identifier

    • createDataChannel

      void createDataChannel()
      Create a new data channel, if data channels are supported.

      Being supported means that the WebRtcEndpoint has been created with data channel support, the client also supports data channels, and they have been negotiated in the SDP exchange. Otherwise, the method throws an exception, indicating that the operation is not possible.

      Data channels can work in either unreliable mode (analogous to User Datagram Protocol or UDP) or reliable mode (analogous to Transmission Control Protocol or TCP). The two modes have a simple distinction:

      • Reliable mode guarantees the transmission of messages and also the order in which they are delivered. This takes extra overhead, thus potentially making this mode slower.
      • Unreliable mode does not guarantee every message will get to the other side nor what order they get there. This removes the overhead, allowing this mode to work much faster.

      If data channels are not supported, this method throws an exception.

    • createDataChannel

      void createDataChannel(Continuation<Void> cont)
      Asynchronous version of createDataChannel: Continuation.onSuccess(F) is called when the action is done. If an error occurs, Continuation.onError(Throwable) is called.
      See Also:

    • createDataChannel

      void createDataChannel(Transaction tx)
      Create a new data channel, if data channels are supported.

      Being supported means that the WebRtcEndpoint has been created with data channel support, the client also supports data channels, and they have been negotiated in the SDP exchange. Otherwise, the method throws an exception, indicating that the operation is not possible.

      Data channels can work in either unreliable mode (analogous to User Datagram Protocol or UDP) or reliable mode (analogous to Transmission Control Protocol or TCP). The two modes have a simple distinction:

      • Reliable mode guarantees the transmission of messages and also the order in which they are delivered. This takes extra overhead, thus potentially making this mode slower.
      • Unreliable mode does not guarantee every message will get to the other side nor what order they get there. This removes the overhead, allowing this mode to work much faster.

      If data channels are not supported, this method throws an exception.

    • createDataChannel

      void createDataChannel(String label)
      Create a new data channel, if data channels are supported.

      Being supported means that the WebRtcEndpoint has been created with data channel support, the client also supports data channels, and they have been negotiated in the SDP exchange. Otherwise, the method throws an exception, indicating that the operation is not possible.

      Data channels can work in either unreliable mode (analogous to User Datagram Protocol or UDP) or reliable mode (analogous to Transmission Control Protocol or TCP). The two modes have a simple distinction:

      • Reliable mode guarantees the transmission of messages and also the order in which they are delivered. This takes extra overhead, thus potentially making this mode slower.
      • Unreliable mode does not guarantee every message will get to the other side nor what order they get there. This removes the overhead, allowing this mode to work much faster.

      If data channels are not supported, this method throws an exception.

      Parameters:
      label - Channel's label

    • createDataChannel

      void createDataChannel(String label, Continuation<Void> cont)
      Asynchronous version of createDataChannel: Continuation.onSuccess(F) is called when the action is done. If an error occurs, Continuation.onError(Throwable) is called.
      Parameters:
      label - Channel's label
      See Also:

    • createDataChannel

      void createDataChannel(Transaction tx, String label)
      Create a new data channel, if data channels are supported.

      Being supported means that the WebRtcEndpoint has been created with data channel support, the client also supports data channels, and they have been negotiated in the SDP exchange. Otherwise, the method throws an exception, indicating that the operation is not possible.

      Data channels can work in either unreliable mode (analogous to User Datagram Protocol or UDP) or reliable mode (analogous to Transmission Control Protocol or TCP). The two modes have a simple distinction:

      • Reliable mode guarantees the transmission of messages and also the order in which they are delivered. This takes extra overhead, thus potentially making this mode slower.
      • Unreliable mode does not guarantee every message will get to the other side nor what order they get there. This removes the overhead, allowing this mode to work much faster.

      If data channels are not supported, this method throws an exception.

      Parameters:
      label - Channel's label

    • createDataChannel

      void createDataChannel(String label, boolean ordered)
      Create a new data channel, if data channels are supported.

      Being supported means that the WebRtcEndpoint has been created with data channel support, the client also supports data channels, and they have been negotiated in the SDP exchange. Otherwise, the method throws an exception, indicating that the operation is not possible.

      Data channels can work in either unreliable mode (analogous to User Datagram Protocol or UDP) or reliable mode (analogous to Transmission Control Protocol or TCP). The two modes have a simple distinction:

      • Reliable mode guarantees the transmission of messages and also the order in which they are delivered. This takes extra overhead, thus potentially making this mode slower.
      • Unreliable mode does not guarantee every message will get to the other side nor what order they get there. This removes the overhead, allowing this mode to work much faster.

      If data channels are not supported, this method throws an exception.

      Parameters:
      label - Channel's label
      ordered - If the data channel should guarantee order or not. If true, and maxPacketLifeTime and maxRetransmits have not been provided, reliable mode is activated.

    • createDataChannel

      void createDataChannel(String label, boolean ordered, Continuation<Void> cont)
      Asynchronous version of createDataChannel: Continuation.onSuccess(F) is called when the action is done. If an error occurs, Continuation.onError(Throwable) is called.
      Parameters:
      label - Channel's label
      ordered - If the data channel should guarantee order or not. If true, and maxPacketLifeTime and maxRetransmits have not been provided, reliable mode is activated.
      See Also:

    • createDataChannel

      void createDataChannel(Transaction tx, String label, boolean ordered)
      Create a new data channel, if data channels are supported.

      Being supported means that the WebRtcEndpoint has been created with data channel support, the client also supports data channels, and they have been negotiated in the SDP exchange. Otherwise, the method throws an exception, indicating that the operation is not possible.

      Data channels can work in either unreliable mode (analogous to User Datagram Protocol or UDP) or reliable mode (analogous to Transmission Control Protocol or TCP). The two modes have a simple distinction:

      • Reliable mode guarantees the transmission of messages and also the order in which they are delivered. This takes extra overhead, thus potentially making this mode slower.
      • Unreliable mode does not guarantee every message will get to the other side nor what order they get there. This removes the overhead, allowing this mode to work much faster.

      If data channels are not supported, this method throws an exception.

      Parameters:
      label - Channel's label
      ordered - If the data channel should guarantee order or not. If true, and maxPacketLifeTime and maxRetransmits have not been provided, reliable mode is activated.

    • createDataChannel

      void createDataChannel(String label, boolean ordered, int maxPacketLifeTime)
      Create a new data channel, if data channels are supported.

      Being supported means that the WebRtcEndpoint has been created with data channel support, the client also supports data channels, and they have been negotiated in the SDP exchange. Otherwise, the method throws an exception, indicating that the operation is not possible.

      Data channels can work in either unreliable mode (analogous to User Datagram Protocol or UDP) or reliable mode (analogous to Transmission Control Protocol or TCP). The two modes have a simple distinction:

      • Reliable mode guarantees the transmission of messages and also the order in which they are delivered. This takes extra overhead, thus potentially making this mode slower.
      • Unreliable mode does not guarantee every message will get to the other side nor what order they get there. This removes the overhead, allowing this mode to work much faster.

      If data channels are not supported, this method throws an exception.

      Parameters:
      label - Channel's label
      ordered - If the data channel should guarantee order or not. If true, and maxPacketLifeTime and maxRetransmits have not been provided, reliable mode is activated.
      maxPacketLifeTime - The time window (in milliseconds) during which transmissions and retransmissions may take place in unreliable mode. Note that this forces unreliable mode, even if ordered has been activated.

    • createDataChannel

      void createDataChannel(String label, boolean ordered, int maxPacketLifeTime, Continuation<Void> cont)
      Asynchronous version of createDataChannel: Continuation.onSuccess(F) is called when the action is done. If an error occurs, Continuation.onError(Throwable) is called.
      Parameters:
      label - Channel's label
      ordered - If the data channel should guarantee order or not. If true, and maxPacketLifeTime and maxRetransmits have not been provided, reliable mode is activated.
      maxPacketLifeTime - The time window (in milliseconds) during which transmissions and retransmissions may take place in unreliable mode. Note that this forces unreliable mode, even if ordered has been activated.
      See Also:

    • createDataChannel

      void createDataChannel(Transaction tx, String label, boolean ordered, int maxPacketLifeTime)
      Create a new data channel, if data channels are supported.

      Being supported means that the WebRtcEndpoint has been created with data channel support, the client also supports data channels, and they have been negotiated in the SDP exchange. Otherwise, the method throws an exception, indicating that the operation is not possible.

      Data channels can work in either unreliable mode (analogous to User Datagram Protocol or UDP) or reliable mode (analogous to Transmission Control Protocol or TCP). The two modes have a simple distinction:

      • Reliable mode guarantees the transmission of messages and also the order in which they are delivered. This takes extra overhead, thus potentially making this mode slower.
      • Unreliable mode does not guarantee every message will get to the other side nor what order they get there. This removes the overhead, allowing this mode to work much faster.

      If data channels are not supported, this method throws an exception.

      Parameters:
      label - Channel's label
      ordered - If the data channel should guarantee order or not. If true, and maxPacketLifeTime and maxRetransmits have not been provided, reliable mode is activated.
      maxPacketLifeTime - The time window (in milliseconds) during which transmissions and retransmissions may take place in unreliable mode. Note that this forces unreliable mode, even if ordered has been activated.

    • createDataChannel

      void createDataChannel(String label, boolean ordered, int maxPacketLifeTime, int maxRetransmits)
      Create a new data channel, if data channels are supported.

      Being supported means that the WebRtcEndpoint has been created with data channel support, the client also supports data channels, and they have been negotiated in the SDP exchange. Otherwise, the method throws an exception, indicating that the operation is not possible.

      Data channels can work in either unreliable mode (analogous to User Datagram Protocol or UDP) or reliable mode (analogous to Transmission Control Protocol or TCP). The two modes have a simple distinction:

      • Reliable mode guarantees the transmission of messages and also the order in which they are delivered. This takes extra overhead, thus potentially making this mode slower.
      • Unreliable mode does not guarantee every message will get to the other side nor what order they get there. This removes the overhead, allowing this mode to work much faster.

      If data channels are not supported, this method throws an exception.

      Parameters:
      label - Channel's label
      ordered - If the data channel should guarantee order or not. If true, and maxPacketLifeTime and maxRetransmits have not been provided, reliable mode is activated.
      maxPacketLifeTime - The time window (in milliseconds) during which transmissions and retransmissions may take place in unreliable mode. Note that this forces unreliable mode, even if ordered has been activated.
      maxRetransmits - maximum number of retransmissions that are attempted in unreliable mode. Note that this forces unreliable mode, even if ordered has been activated.

    • createDataChannel

      void createDataChannel(String label, boolean ordered, int maxPacketLifeTime, int maxRetransmits, Continuation<Void> cont)
      Asynchronous version of createDataChannel: Continuation.onSuccess(F) is called when the action is done. If an error occurs, Continuation.onError(Throwable) is called.
      Parameters:
      label - Channel's label
      ordered - If the data channel should guarantee order or not. If true, and maxPacketLifeTime and maxRetransmits have not been provided, reliable mode is activated.
      maxPacketLifeTime - The time window (in milliseconds) during which transmissions and retransmissions may take place in unreliable mode. Note that this forces unreliable mode, even if ordered has been activated.
      maxRetransmits - maximum number of retransmissions that are attempted in unreliable mode. Note that this forces unreliable mode, even if ordered has been activated.
      See Also:

    • createDataChannel

      void createDataChannel(Transaction tx, String label, boolean ordered, int maxPacketLifeTime, int maxRetransmits)
      Create a new data channel, if data channels are supported.

      Being supported means that the WebRtcEndpoint has been created with data channel support, the client also supports data channels, and they have been negotiated in the SDP exchange. Otherwise, the method throws an exception, indicating that the operation is not possible.

      Data channels can work in either unreliable mode (analogous to User Datagram Protocol or UDP) or reliable mode (analogous to Transmission Control Protocol or TCP). The two modes have a simple distinction:

      • Reliable mode guarantees the transmission of messages and also the order in which they are delivered. This takes extra overhead, thus potentially making this mode slower.
      • Unreliable mode does not guarantee every message will get to the other side nor what order they get there. This removes the overhead, allowing this mode to work much faster.

      If data channels are not supported, this method throws an exception.

      Parameters:
      label - Channel's label
      ordered - If the data channel should guarantee order or not. If true, and maxPacketLifeTime and maxRetransmits have not been provided, reliable mode is activated.
      maxPacketLifeTime - The time window (in milliseconds) during which transmissions and retransmissions may take place in unreliable mode. Note that this forces unreliable mode, even if ordered has been activated.
      maxRetransmits - maximum number of retransmissions that are attempted in unreliable mode. Note that this forces unreliable mode, even if ordered has been activated.

    • addIceCandidateFoundListener

      ListenerSubscription addIceCandidateFoundListener(EventListener<IceCandidateFoundEvent> listener)
      Add a EventListener for event IceCandidateFoundEvent. Synchronous call.
      Parameters:
      listener - Listener to be called on IceCandidateFoundEvent
      Returns:
      ListenerSubscription for the given Listener

    • addIceCandidateFoundListener

      void addIceCandidateFoundListener(EventListener<IceCandidateFoundEvent> listener, Continuation<ListenerSubscription> cont)
      Add a EventListener for event IceCandidateFoundEvent. Asynchronous call. Calls Continuation<ListenerSubscription> when it has been added.
      Parameters:
      listener - Listener to be called on IceCandidateFoundEvent
      cont - Continuation to be called when the listener is registered

    • removeIceCandidateFoundListener

      void removeIceCandidateFoundListener(ListenerSubscription listenerSubscription)
      Remove a ListenerSubscription for event IceCandidateFoundEvent. Synchronous call.
      Parameters:
      listenerSubscription - Listener subscription to be removed

    • removeIceCandidateFoundListener

      void removeIceCandidateFoundListener(ListenerSubscription listenerSubscription, Continuation<Void> cont)
      Remove a ListenerSubscription for event IceCandidateFoundEvent. Asynchronous call. Calls Continuation<Void> when it has been removed.
      Parameters:
      listenerSubscription - Listener subscription to be removed
      cont - Continuation to be called when the listener is removed

    • addIceGatheringDoneListener

      ListenerSubscription addIceGatheringDoneListener(EventListener<IceGatheringDoneEvent> listener)
      Add a EventListener for event IceGatheringDoneEvent. Synchronous call.
      Parameters:
      listener - Listener to be called on IceGatheringDoneEvent
      Returns:
      ListenerSubscription for the given Listener

    • addIceGatheringDoneListener

      void addIceGatheringDoneListener(EventListener<IceGatheringDoneEvent> listener, Continuation<ListenerSubscription> cont)
      Add a EventListener for event IceGatheringDoneEvent. Asynchronous call. Calls Continuation<ListenerSubscription> when it has been added.
      Parameters:
      listener - Listener to be called on IceGatheringDoneEvent
      cont - Continuation to be called when the listener is registered

    • removeIceGatheringDoneListener

      void removeIceGatheringDoneListener(ListenerSubscription listenerSubscription)
      Remove a ListenerSubscription for event IceGatheringDoneEvent. Synchronous call.
      Parameters:
      listenerSubscription - Listener subscription to be removed

    • removeIceGatheringDoneListener

      void removeIceGatheringDoneListener(ListenerSubscription listenerSubscription, Continuation<Void> cont)
      Remove a ListenerSubscription for event IceGatheringDoneEvent. Asynchronous call. Calls Continuation<Void> when it has been removed.
      Parameters:
      listenerSubscription - Listener subscription to be removed
      cont - Continuation to be called when the listener is removed

    • addIceComponentStateChangedListener

      ListenerSubscription addIceComponentStateChangedListener(EventListener<IceComponentStateChangedEvent> listener)
      Add a EventListener for event IceComponentStateChangedEvent. Synchronous call.
      Parameters:
      listener - Listener to be called on IceComponentStateChangedEvent
      Returns:
      ListenerSubscription for the given Listener

    • addIceComponentStateChangedListener

      void addIceComponentStateChangedListener(EventListener<IceComponentStateChangedEvent> listener, Continuation<ListenerSubscription> cont)
      Add a EventListener for event IceComponentStateChangedEvent. Asynchronous call. Calls Continuation<ListenerSubscription> when it has been added.
      Parameters:
      listener - Listener to be called on IceComponentStateChangedEvent
      cont - Continuation to be called when the listener is registered

    • removeIceComponentStateChangedListener

      void removeIceComponentStateChangedListener(ListenerSubscription listenerSubscription)
      Remove a ListenerSubscription for event IceComponentStateChangedEvent. Synchronous call.
      Parameters:
      listenerSubscription - Listener subscription to be removed

    • removeIceComponentStateChangedListener

      void removeIceComponentStateChangedListener(ListenerSubscription listenerSubscription, Continuation<Void> cont)
      Remove a ListenerSubscription for event IceComponentStateChangedEvent. Asynchronous call. Calls Continuation<Void> when it has been removed.
      Parameters:
      listenerSubscription - Listener subscription to be removed
      cont - Continuation to be called when the listener is removed

    • addDtlsConnectionStateChangeListener

      ListenerSubscription addDtlsConnectionStateChangeListener(EventListener<DtlsConnectionStateChangeEvent> listener)
      Add a EventListener for event DtlsConnectionStateChangeEvent. Synchronous call.
      Parameters:
      listener - Listener to be called on DtlsConnectionStateChangeEvent
      Returns:
      ListenerSubscription for the given Listener

    • addDtlsConnectionStateChangeListener

      void addDtlsConnectionStateChangeListener(EventListener<DtlsConnectionStateChangeEvent> listener, Continuation<ListenerSubscription> cont)
      Add a EventListener for event DtlsConnectionStateChangeEvent. Asynchronous call. Calls Continuation<ListenerSubscription> when it has been added.
      Parameters:
      listener - Listener to be called on DtlsConnectionStateChangeEvent
      cont - Continuation to be called when the listener is registered

    • removeDtlsConnectionStateChangeListener

      void removeDtlsConnectionStateChangeListener(ListenerSubscription listenerSubscription)
      Remove a ListenerSubscription for event DtlsConnectionStateChangeEvent. Synchronous call.
      Parameters:
      listenerSubscription - Listener subscription to be removed

    • removeDtlsConnectionStateChangeListener

      void removeDtlsConnectionStateChangeListener(ListenerSubscription listenerSubscription, Continuation<Void> cont)
      Remove a ListenerSubscription for event DtlsConnectionStateChangeEvent. Asynchronous call. Calls Continuation<Void> when it has been removed.
      Parameters:
      listenerSubscription - Listener subscription to be removed
      cont - Continuation to be called when the listener is removed

    • addDataChannelOpenedListener

      ListenerSubscription addDataChannelOpenedListener(EventListener<DataChannelOpenedEvent> listener)
      Add a EventListener for event DataChannelOpenedEvent. Synchronous call.
      Parameters:
      listener - Listener to be called on DataChannelOpenedEvent
      Returns:
      ListenerSubscription for the given Listener

    • addDataChannelOpenedListener

      void addDataChannelOpenedListener(EventListener<DataChannelOpenedEvent> listener, Continuation<ListenerSubscription> cont)
      Add a EventListener for event DataChannelOpenedEvent. Asynchronous call. Calls Continuation<ListenerSubscription> when it has been added.
      Parameters:
      listener - Listener to be called on DataChannelOpenedEvent
      cont - Continuation to be called when the listener is registered

    • removeDataChannelOpenedListener

      void removeDataChannelOpenedListener(ListenerSubscription listenerSubscription)
      Remove a ListenerSubscription for event DataChannelOpenedEvent. Synchronous call.
      Parameters:
      listenerSubscription - Listener subscription to be removed

    • removeDataChannelOpenedListener

      void removeDataChannelOpenedListener(ListenerSubscription listenerSubscription, Continuation<Void> cont)
      Remove a ListenerSubscription for event DataChannelOpenedEvent. Asynchronous call. Calls Continuation<Void> when it has been removed.
      Parameters:
      listenerSubscription - Listener subscription to be removed
      cont - Continuation to be called when the listener is removed

    • addDataChannelClosedListener

      ListenerSubscription addDataChannelClosedListener(EventListener<DataChannelClosedEvent> listener)
      Add a EventListener for event DataChannelClosedEvent. Synchronous call.
      Parameters:
      listener - Listener to be called on DataChannelClosedEvent
      Returns:
      ListenerSubscription for the given Listener

    • addDataChannelClosedListener

      void addDataChannelClosedListener(EventListener<DataChannelClosedEvent> listener, Continuation<ListenerSubscription> cont)
      Add a EventListener for event DataChannelClosedEvent. Asynchronous call. Calls Continuation<ListenerSubscription> when it has been added.
      Parameters:
      listener - Listener to be called on DataChannelClosedEvent
      cont - Continuation to be called when the listener is registered

    • removeDataChannelClosedListener

      void removeDataChannelClosedListener(ListenerSubscription listenerSubscription)
      Remove a ListenerSubscription for event DataChannelClosedEvent. Synchronous call.
      Parameters:
      listenerSubscription - Listener subscription to be removed

    • removeDataChannelClosedListener

      void removeDataChannelClosedListener(ListenerSubscription listenerSubscription, Continuation<Void> cont)
      Remove a ListenerSubscription for event DataChannelClosedEvent. Asynchronous call. Calls Continuation<Void> when it has been removed.
      Parameters:
      listenerSubscription - Listener subscription to be removed
      cont - Continuation to be called when the listener is removed

    • addNewCandidatePairSelectedListener

      ListenerSubscription addNewCandidatePairSelectedListener(EventListener<NewCandidatePairSelectedEvent> listener)
      Add a EventListener for event NewCandidatePairSelectedEvent. Synchronous call.
      Parameters:
      listener - Listener to be called on NewCandidatePairSelectedEvent
      Returns:
      ListenerSubscription for the given Listener

    • addNewCandidatePairSelectedListener

      void addNewCandidatePairSelectedListener(EventListener<NewCandidatePairSelectedEvent> listener, Continuation<ListenerSubscription> cont)
      Add a EventListener for event NewCandidatePairSelectedEvent. Asynchronous call. Calls Continuation<ListenerSubscription> when it has been added.
      Parameters:
      listener - Listener to be called on NewCandidatePairSelectedEvent
      cont - Continuation to be called when the listener is registered

    • removeNewCandidatePairSelectedListener

      void removeNewCandidatePairSelectedListener(ListenerSubscription listenerSubscription)
      Remove a ListenerSubscription for event NewCandidatePairSelectedEvent. Synchronous call.
      Parameters:
      listenerSubscription - Listener subscription to be removed

    • removeNewCandidatePairSelectedListener

      void removeNewCandidatePairSelectedListener(ListenerSubscription listenerSubscription, Continuation<Void> cont)
      Remove a ListenerSubscription for event NewCandidatePairSelectedEvent. Asynchronous call. Calls Continuation<Void> when it has been removed.
      Parameters:
      listenerSubscription - Listener subscription to be removed
      cont - Continuation to be called when the listener is removed