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 Detail

      • 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
      • 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.
      • 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​(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​(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(java.lang.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(java.lang.String, boolean, int, int, java.lang.String)
      • 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​(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​(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​(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​(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​(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(java.lang.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(java.lang.String, boolean, int, int, java.lang.String)
      • 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.
      • 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
      • 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
      • 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
      • 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
      • 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
      • 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