New Case Study:See how Anthropic automated 95% of dependency reviews with Socket.Learn More →
kurento-client-elements
Advanced tools
kurento-client-elements - npm Package Compare versions
Comparing version 6.5.0 to 6.6.0
@@ -75,2 +75,8 @@ /* Autogenerated with Kurento Idl */ | ||
| var usePromise = false; | ||
| if (callback == undefined) { | ||
| usePromise = true; | ||
| } | ||
| if(!arguments.length) callback = undefined; | ||
@@ -77,0 +83,0 @@ |
@@ -28,2 +28,3 @@ /* Autogenerated with Kurento Idl */ | ||
| var CertificateKeyType = require('./CertificateKeyType'); | ||
| var CryptoSuite = require('./CryptoSuite'); | ||
@@ -39,2 +40,3 @@ var IceCandidate = require('./IceCandidate'); | ||
| exports.CertificateKeyType = CertificateKeyType; | ||
| exports.CryptoSuite = CryptoSuite; | ||
@@ -41,0 +43,0 @@ exports.IceCandidate = IceCandidate; |
@@ -25,7 +25,7 @@ /* Autogenerated with Kurento Idl */ | ||
| * Media Profile. | ||
| * Currently WEBM and MP4 are supported. | ||
| * Currently WEBM, MP4 and JPEG are supported. | ||
| * | ||
| * @typedef elements/complexTypes.MediaProfileSpecType | ||
| * | ||
| * @type {(WEBM|MP4|WEBM_VIDEO_ONLY|WEBM_AUDIO_ONLY|MP4_VIDEO_ONLY|MP4_AUDIO_ONLY|KURENTO_SPLIT_RECORDER)} | ||
| * @type {(WEBM|MP4|WEBM_VIDEO_ONLY|WEBM_AUDIO_ONLY|MP4_VIDEO_ONLY|MP4_AUDIO_ONLY|JPEG_VIDEO_ONLY|KURENTO_SPLIT_RECORDER)} | ||
| */ | ||
@@ -46,4 +46,4 @@ | ||
| if(!value.match('WEBM|MP4|WEBM_VIDEO_ONLY|WEBM_AUDIO_ONLY|MP4_VIDEO_ONLY|MP4_AUDIO_ONLY|KURENTO_SPLIT_RECORDER')) | ||
| throw SyntaxError(key+' param is not one of [WEBM|MP4|WEBM_VIDEO_ONLY|WEBM_AUDIO_ONLY|MP4_VIDEO_ONLY|MP4_AUDIO_ONLY|KURENTO_SPLIT_RECORDER] ('+value+')'); | ||
| if(!value.match('WEBM|MP4|WEBM_VIDEO_ONLY|WEBM_AUDIO_ONLY|MP4_VIDEO_ONLY|MP4_AUDIO_ONLY|JPEG_VIDEO_ONLY|KURENTO_SPLIT_RECORDER')) | ||
| throw SyntaxError(key+' param is not one of [WEBM|MP4|WEBM_VIDEO_ONLY|WEBM_AUDIO_ONLY|MP4_VIDEO_ONLY|MP4_AUDIO_ONLY|JPEG_VIDEO_ONLY|KURENTO_SPLIT_RECORDER] ('+value+')'); | ||
| }; | ||
@@ -50,0 +50,0 @@ |
@@ -76,2 +76,8 @@ /* Autogenerated with Kurento Idl */ | ||
| var usePromise = false; | ||
| if (callback == undefined) { | ||
| usePromise = true; | ||
| } | ||
| if(!arguments.length) callback = undefined; | ||
@@ -78,0 +84,0 @@ |
@@ -94,4 +94,3 @@ /* Autogenerated with Kurento Idl */ | ||
| /** | ||
| * @deprecated | ||
| * Event fired when a data channel is closed. | ||
| * @deprecated</br>Event fired when a data channel is closed. | ||
| * | ||
@@ -107,4 +106,3 @@ * @event module:elements#OnDataChannelClosed | ||
| /** | ||
| * @deprecated | ||
| * Event fired when a new data channel is created. | ||
| * @deprecated</br>Event fired when a new data channel is created. | ||
| * | ||
@@ -120,4 +118,4 @@ * @event module:elements#OnDataChannelOpened | ||
| /** | ||
| * @deprecated | ||
| * Notifies a new local candidate. These candidates should be sent to the remote | ||
| * @deprecated</br>Notifies a new local candidate. These candidates should be | ||
| * sent to the remote peer, to complete the ICE negotiation process. | ||
| * | ||
@@ -133,4 +131,3 @@ * @event module:elements#OnIceCandidate | ||
| /** | ||
| * @deprecated | ||
| * Event fired when and ICE component state changes. See | ||
| * @deprecated</br>Event fired when and ICE component state changes. See | ||
| * :rom:cls:`IceComponentState` for a list of possible states. | ||
@@ -151,4 +148,3 @@ * | ||
| /** | ||
| * @deprecated | ||
| * Event fired when al ICE candidates have been gathered. | ||
| * @deprecated</br>Event fired when al ICE candidates have been gathered. | ||
| * | ||
@@ -171,3 +167,3 @@ * @event module:elements#OnIceGatheringDone | ||
| /** | ||
| * Fired when the recorder goes to pause state | ||
| * @deprecated</br>Fired when the recorder goes to pause state | ||
| * | ||
@@ -185,6 +181,6 @@ * @event module:elements#Paused | ||
| /** | ||
| * Fired when the recorder has been stopped and all the media has been written | ||
| * to storage. | ||
| * @deprecated</br>Fired when the recorder has been stopped and all the media | ||
| * has been written to storage. | ||
| * | ||
| * @event module:elements#Stopped | ||
| */ |
@@ -29,3 +29,3 @@ /* Autogenerated with Kurento Idl */ | ||
| Object.defineProperty(exports, 'name', {value: 'elements'}); | ||
| Object.defineProperty(exports, 'version', {value: '6.5.0'}); | ||
| Object.defineProperty(exports, 'version', {value: '6.6.0'}); | ||
@@ -32,0 +32,0 @@ |
@@ -134,2 +134,8 @@ /* Autogenerated with Kurento Idl */ | ||
| var usePromise = false; | ||
| if (callback == undefined) { | ||
| usePromise = true; | ||
| } | ||
| if(!arguments.length) callback = undefined; | ||
@@ -192,2 +198,8 @@ | ||
| var usePromise = false; | ||
| if (callback == undefined) { | ||
| usePromise = true; | ||
| } | ||
| if(!arguments.length) callback = undefined; | ||
@@ -227,2 +239,8 @@ | ||
| var usePromise = false; | ||
| if (callback == undefined) { | ||
| usePromise = true; | ||
| } | ||
| if(!arguments.length) callback = undefined; | ||
@@ -247,2 +265,5 @@ | ||
| * | ||
| * @property {external:Integer} [networkCache] | ||
| * When using rtsp sources. Amount of ms to buffer | ||
| * | ||
| * @property {external:String} uri | ||
@@ -265,2 +286,4 @@ * URI pointing to the video. It has to be accessible to the KMS process. | ||
| }, | ||
| networkCache: { | ||
| type: 'int' }, | ||
| uri: { | ||
@@ -267,0 +290,0 @@ type: 'String', |
@@ -170,2 +170,8 @@ /* Autogenerated with Kurento Idl */ | ||
| var usePromise = false; | ||
| if (callback == undefined) { | ||
| usePromise = true; | ||
| } | ||
| if(!arguments.length) callback = undefined; | ||
@@ -196,2 +202,8 @@ | ||
| var usePromise = false; | ||
| if (callback == undefined) { | ||
| usePromise = true; | ||
| } | ||
| if(!arguments.length) callback = undefined; | ||
@@ -198,0 +210,0 @@ |
@@ -59,14 +59,16 @@ /* Autogenerated with Kurento Idl */ | ||
| * This endpoint can function in both situations | ||
| * <ul style='list-style-type:circle'> | ||
| * <ul> | ||
| * <li> | ||
| * As offerer: The negotiation process is initiated by the media | ||
| * server | ||
| * <ul> | ||
| * <li>KMS generates the SDP offer through the generateOffer | ||
| * method. This offer must then be sent to the remote peer (the | ||
| * offeree) through the signaling channel, for processing.</li> | ||
| * <li>The remote peer process the Offer, and generates an Answer | ||
| * to this offer. The Answer is sent back to the media server.</li> | ||
| * <li>Upon receiving the Answer, the endpoint must invoke the | ||
| * processAnswer method.</li> | ||
| * <ul style='list-style-type:circle'> | ||
| * <li>KMS generates the SDP offer through the | ||
| * <code>generateOffer</code> method. This <i>offer</i> must then | ||
| * be sent to the remote peer (the offeree) through the signaling | ||
| * channel, for processing.</li> | ||
| * <li>The remote peer process the <i>offer</i>, and generates an | ||
| * <i>answer</i> to this <i>offer</i>. The <i>answer</i> is sent | ||
| * back to the media server.</li> | ||
| * <li>Upon receiving the <i>answer</i>, the endpoint must invoke | ||
| * the <code>processAnswer</code> method.</li> | ||
| * </ul> | ||
@@ -78,8 +80,9 @@ * </li> | ||
| * <ul> | ||
| * <li>The remote peer, acting as offerer, generates an SDP offer | ||
| * and sends it to the WebRTC endpoint in Kurento.</li> | ||
| * <li>The endpoint will process the Offer invoking the | ||
| * processOffer method. The result of this method will be a string, | ||
| * <li>The SDP Answer must be sent back to the offerer, so it can | ||
| * be processed.</li> | ||
| * <li>The remote peer, acting as offerer, generates an SDP | ||
| * <i>offer</i> and sends it to the WebRTC endpoint in | ||
| * Kurento.</li> | ||
| * <li>The endpoint will process the <i>offer</i> invoking the | ||
| * <code>processOffer</code> method. The result of this method will | ||
| * <li>The SDP <i>answer</i> must be sent back to the offerer, so | ||
| * it can be processed.</li> | ||
| * </ul> | ||
@@ -90,5 +93,2 @@ * </li> | ||
| * <p> | ||
| * TODO: Comentar que se puede hacer Vanilla ICE o Trickle ICE | ||
| * </p> | ||
| * <p> | ||
| * SDPs are sent without ICE candidates, following the Trickle ICE | ||
@@ -109,19 +109,20 @@ * optimization. Once the SDP negotiation is completed, both peers | ||
| * <p> | ||
| * It’s important to keep in mind that WebRTC connection is an | ||
| * It's 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 | ||
| * <ul style='list-style-type:circle'> | ||
| * <ul> | ||
| * <li> | ||
| * OnIceComponentStateChanged: This event informs only about changes | ||
| * in the ICE connection state. Possible values are: | ||
| * <ul> | ||
| * <li>DISCONNECTED: No activity scheduled</li> | ||
| * <li>GATHERING: Gathering local candidates</li> | ||
| * <li>CONNECTING: Establishing connectivity</li> | ||
| * <li>CONNECTED: At least one working candidate pair</li> | ||
| * <li>READY: ICE concluded, candidate pair selection is now | ||
| * final</li> | ||
| * <li>FAILED: Connectivity checks have been completed, but media | ||
| * connection was not established</li> | ||
| * <code>IceComponentStateChange</code>: This event informs only | ||
| * about changes in the ICE connection state. Possible values are: | ||
| * <ul style='list-style-type:circle'> | ||
| * <li><code>DISCONNECTED</code>: No activity scheduled</li> | ||
| * <li><code>GATHERING</code>: Gathering local candidates</li> | ||
| * <li><code>CONNECTING</code>: Establishing connectivity</li> | ||
| * <li><code>CONNECTED</code>: At least one working candidate | ||
| * pair</li> | ||
| * <li><code>READY</code>: ICE concluded, candidate pair selection | ||
| * is now final</li> | ||
| * <li><code>FAILED</code>: Connectivity checks have been | ||
| * completed, but media connection was not established</li> | ||
| * </ul> | ||
@@ -133,23 +134,25 @@ * The transitions between states are covered in RFC5245. | ||
| * <li> | ||
| * OnIceCandidate: 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. | ||
| * <code>IceCandidateFound</code>: 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. | ||
| * </li> | ||
| * <li> | ||
| * OnIceGatheringDone: Raised when the ICE harvesting process is | ||
| * completed. This means that all candidates have already been | ||
| * discovered. | ||
| * <code>IceGatheringDone</code>: Raised when the ICE harvesting | ||
| * process is completed. This means that all candidates have already | ||
| * been discovered. | ||
| * </li> | ||
| * <li> | ||
| * 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 | ||
| * <code>NewCandidatePairSelected</code>: 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. | ||
| * </li> | ||
| * <li> | ||
| * OnDataChannelOpened: Raised when a data channel is open. | ||
| * <code>DataChannelOpen</code>: Raised when a data channel is open. | ||
| * </li> | ||
| * <li> | ||
| * OnDataChannelClosed: Raised when a data channel is closed. | ||
| * <code>DataChannelClose</code>: Raised when a data channel is | ||
| * closed. | ||
| * </li> | ||
@@ -167,3 +170,3 @@ * </ul> | ||
| * The default bandwidth range of the endpoint is 100kbps-500kbps, but it | ||
| * <ul style='list-style-type:circle'> | ||
| * <ul> | ||
| * <li> | ||
@@ -173,3 +176,3 @@ * Input bandwidth control mechanism: Configuration interval used to | ||
| * this WebRtcEndpoint object. | ||
| * <ul> | ||
| * <ul style='list-style-type:circle'> | ||
| * <li> | ||
@@ -189,10 +192,6 @@ * setMin/MaxVideoRecvBandwidth: sets Min/Max bitrate limits | ||
| * Output bandwidth control mechanism: Configuration interval used to | ||
| * <ul> | ||
| * <ul style='list-style-type:circle'> | ||
| * <li> | ||
| * setMin/MaxVideoSendBandwidth: sets Min/Max bitrate limits for | ||
| * </li> | ||
| * <li> | ||
| * setMin/MaxAudioSendBandwidth: sets Min/Max bitrate limits for | ||
| * audio sent to remote peer. | ||
| * </li> | ||
| * </ul> | ||
@@ -207,3 +206,3 @@ * </li> | ||
| * to send arbitrary data. For instance, if there is a filter that | ||
| * publishes event information, it’ll be sent to the remote peer through | ||
| * publishes event information, it'll be sent to the remote peer through | ||
| * the channel. There is no API available for programmers to make use of | ||
@@ -222,6 +221,3 @@ * this feature in the WebRtcElement. DataChannels can be configured to | ||
| * 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. | ||
| * However, the channel can be configured to be <i>partially reliable</i> | ||
| * </p> | ||
@@ -234,17 +230,24 @@ * <p> | ||
| * <li> | ||
| * `label`: assigns a label to the DataChannel. This can help | ||
| * identify each possible channel separately. | ||
| * <code>label</code>: assigns a label to the DataChannel. This can | ||
| * help identify each possible channel separately. | ||
| * </li> | ||
| * <li> | ||
| * `ordered`: specifies if the DataChannel guarantees order, which is | ||
| * <code>ordered</code>: specifies if the DataChannel guarantees | ||
| * order, which is the default mode. If maxPacketLifetime and | ||
| * maxRetransmits have not been set, this enables reliable mode. | ||
| * </li> | ||
| * <li> | ||
| * `maxPacketLifeTime`: The time window in milliseconds, during which | ||
| * <code>maxPacketLifeTime</code>: The time window in milliseconds, | ||
| * during which transmissions and retransmissions may take place in | ||
| * unreliable mode. This forces unreliable mode, even if | ||
| * <code>ordered</code> has been activated. | ||
| * </li> | ||
| * <li> | ||
| * `maxRetransmits`: maximum number of retransmissions that are | ||
| * attempted in unreliable mode. This forces unreliable mode, even if | ||
| * <code>maxRetransmits</code>: maximum number of retransmissions | ||
| * that are attempted in unreliable mode. This forces unreliable | ||
| * mode, even if <code>ordered</code> has been activated. | ||
| * </li> | ||
| * <li> | ||
| * `Protocol`: Name of the subprotocol used for data communication. | ||
| * <code>Protocol</code>: Name of the subprotocol used for data | ||
| * communication. | ||
| * </li> | ||
@@ -280,3 +283,3 @@ * </ul> | ||
| /** | ||
| * The ICE candidate pair (local and remote candidates) used by the ice library | ||
| * the ICE candidate pair (local and remote candidates) used by the ice library | ||
| * for each stream. | ||
@@ -295,2 +298,8 @@ * | ||
| var usePromise = false; | ||
| if (callback == undefined) { | ||
| usePromise = true; | ||
| } | ||
| if(!arguments.length) callback = undefined; | ||
@@ -309,3 +318,3 @@ | ||
| /** | ||
| * The ICE connection state for all the connections. | ||
| * the ICE connection state for all the connections. | ||
| * | ||
@@ -323,2 +332,8 @@ * @alias module:elements.WebRtcEndpoint#getIceConnectionState | ||
| var usePromise = false; | ||
| if (callback == undefined) { | ||
| usePromise = true; | ||
| } | ||
| if(!arguments.length) callback = undefined; | ||
@@ -337,3 +352,3 @@ | ||
| /** | ||
| * Address of the STUN server (Only IP address are supported) | ||
| * address of the STUN server (Only IP address are supported) | ||
| * | ||
@@ -351,2 +366,8 @@ * @alias module:elements.WebRtcEndpoint#getStunServerAddress | ||
| var usePromise = false; | ||
| if (callback == undefined) { | ||
| usePromise = true; | ||
| } | ||
| if(!arguments.length) callback = undefined; | ||
@@ -365,3 +386,3 @@ | ||
| /** | ||
| * Address of the STUN server (Only IP address are supported) | ||
| * address of the STUN server (Only IP address are supported) | ||
| * | ||
@@ -396,3 +417,3 @@ * @alias module:elements.WebRtcEndpoint#setStunServerAddress | ||
| /** | ||
| * Port of the STUN server | ||
| * port of the STUN server | ||
| * | ||
@@ -410,2 +431,8 @@ * @alias module:elements.WebRtcEndpoint#getStunServerPort | ||
| var usePromise = false; | ||
| if (callback == undefined) { | ||
| usePromise = true; | ||
| } | ||
| if(!arguments.length) callback = undefined; | ||
@@ -424,3 +451,3 @@ | ||
| /** | ||
| * Port of the STUN server | ||
| * port of the STUN server | ||
| * | ||
@@ -456,5 +483,3 @@ * @alias module:elements.WebRtcEndpoint#setStunServerPort | ||
| * TURN server URL with this format: | ||
| * 'user:password@address:port(?transport=[udp|tcp|tls])'. | ||
| * 'address' must be an IP (not a domain). | ||
| * 'transport' is optional (UDP by default). | ||
| * <code>user:password@address:port(?transport=[udp|tcp|tls])</code>.</br><code>address</code> | ||
| * | ||
@@ -472,2 +497,8 @@ * @alias module:elements.WebRtcEndpoint#getTurnUrl | ||
| var usePromise = false; | ||
| if (callback == undefined) { | ||
| usePromise = true; | ||
| } | ||
| if(!arguments.length) callback = undefined; | ||
@@ -487,5 +518,3 @@ | ||
| * TURN server URL with this format: | ||
| * 'user:password@address:port(?transport=[udp|tcp|tls])'. | ||
| * 'address' must be an IP (not a domain). | ||
| * 'transport' is optional (UDP by default). | ||
| * <code>user:password@address:port(?transport=[udp|tcp|tls])</code>.</br><code>address</code> | ||
| * | ||
@@ -617,10 +646,11 @@ * @alias module:elements.WebRtcEndpoint#setTurnUrl | ||
| * The time window (in milliseconds) during which transmissions and | ||
| * retransmissions may take place in unreliable mode. | ||
| * <hr/><b>Note</b> This forces unreliable mode, even if ordered | ||
| * has been activated | ||
| * retransmissions may take place in unreliable mode.</br> | ||
| * <hr/><b>Note</b> This forces unreliable mode, even if | ||
| * <code>ordered</code> has been activated | ||
| * | ||
| * @param {external:Integer} [maxRetransmits] | ||
| * maximum number of retransmissions that are attempted in unreliable mode. | ||
| * <hr/><b>Note</b> This forces unreliable mode, even if ordered | ||
| * has been activated | ||
| * maximum number of retransmissions that are attempted in unreliable | ||
| * mode.</br> | ||
| * <hr/><b>Note</b> This forces unreliable mode, even if | ||
| * <code>ordered</code> has been activated | ||
| * | ||
@@ -686,7 +716,5 @@ * @param {external:String} [protocol] | ||
| /** | ||
| * Start the gathering of ICE candidates. | ||
| * It must be called after SdpEndpoint::generateOffer or | ||
| * SdpEndpoint::processOffer for Trickle ICE. If invoked before generating or | ||
| * processing an SDP offer, the candidates gathered will be added to the SDP | ||
| * processed. | ||
| * Start the gathering of ICE candidates.</br>It must be called after | ||
| * SdpEndpoint::generateOffer or SdpEndpoint::processOffer for Trickle ICE. If | ||
| * invoked before generating or processing an SDP offer, the candidates gathered | ||
| * | ||
@@ -704,2 +732,8 @@ * @alias module:elements.WebRtcEndpoint.gatherCandidates | ||
| var usePromise = false; | ||
| if (callback == undefined) { | ||
| usePromise = true; | ||
| } | ||
| if(!arguments.length) callback = undefined; | ||
@@ -720,2 +754,5 @@ | ||
| * | ||
| * @property {module:elements/complexTypes.CertificateKeyType} [certificateKeyType] | ||
| * Define the type of the certificate used in dtls | ||
| * | ||
| * @property {module:core.MediaPipeline} mediaPipeline | ||
@@ -729,2 +766,4 @@ * the {@link module:core.MediaPipeline MediaPipeline} to which the endpoint | ||
| WebRtcEndpoint.constructorParams = { | ||
| certificateKeyType: { | ||
| type: 'kurento.CertificateKeyType' }, | ||
| mediaPipeline: { | ||
@@ -731,0 +770,0 @@ type: 'kurento.MediaPipeline', |
| { | ||
| "name": "kurento-client-elements", | ||
| "version": "6.5.0", | ||
| "version": "6.6.0", | ||
| "description": "Elements implementations for kurento media server", | ||
@@ -5,0 +5,0 @@ "main": "lib/index.js", |
| { | ||
| "name": "elements", | ||
| "version": "6.5.0", | ||
| "version": "6.6.0", | ||
| "kurentoVersion": "^6.1.0", | ||
@@ -18,3 +18,3 @@ "imports": [ | ||
| "mavenArtifactId": "kms-api-elements", | ||
| "mavenVersion": "6.5.0" | ||
| "mavenVersion": "6.6.0" | ||
| } | ||
@@ -27,3 +27,3 @@ }, | ||
| "mavenArtifactId": "kurento-client", | ||
| "mavenVersion": "6.5.0" | ||
| "mavenVersion": "6.6.0" | ||
| }, | ||
@@ -34,3 +34,3 @@ "js": { | ||
| "npmGit": "Kurento/kurento-client-elements-js", | ||
| "npmVersion": "6.5.0" | ||
| "npmVersion": "6.6.0" | ||
| } | ||
@@ -79,3 +79,3 @@ }, | ||
| "name": "WebRtcEndpoint", | ||
| "doc": "<p>\n Control interface for Kurento WebRTC endpoint.\n </p>\n <p>\n This endpoint is one side of a peer-to-peer WebRTC communication, being the other peer a WebRTC capable browser -using the RTCPeerConnection API-, a native WebRTC app or even another Kurento Media Server.\n </p>\n <p>\n In order to establish a WebRTC communication, peers engage in an SDP negotiation process, where one of the peers (the offerer) sends an offer, while the other peer (the offeree) responds with an answer. This endpoint can function in both situations\n <ul style='list-style-type:circle'>\n <li>\n As offerer: The negotiation process is initiated by the media server\n <ul>\n <li>KMS generates the SDP offer through the generateOffer method. This offer must then be sent to the remote peer (the offeree) through the signaling channel, for processing.</li>\n <li>The remote peer process the Offer, and generates an Answer to this offer. The Answer is sent back to the media server.</li>\n <li>Upon receiving the Answer, the endpoint must invoke the processAnswer method.</li>\n </ul>\n </li>\n <li>\n As offeree: The negotiation process is initiated by the remote peer\n <ul>\n <li>The remote peer, acting as offerer, generates an SDP offer and sends it to the WebRTC endpoint in Kurento.</li>\n <li>The endpoint will process the Offer invoking the processOffer method. The result of this method will be a string, containing an SDP Answer.</li>\n <li>The SDP Answer must be sent back to the offerer, so it can be processed.</li>\n </ul>\n </li>\n </ul>\n </p>\n <p>\n TODO: Comentar que se puede hacer Vanilla ICE o Trickle ICE\n </p>\n <p>\n 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\n <ul>\n <li>Discovers ICE candidates for itself, containing pairs of IPs and ports.</li>\n <li>ICE candidates are sent via the signaling channel as they are discovered, to the remote peer for probing.</li>\n <li>ICE connectivity checks are run as soon as the new candidate description, from the remote peer, is available.</li>\n </ul>\n 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 OnIceCandidate. 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.\n </p>\n <p>\n It’s 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:\n <ul style='list-style-type:circle'>\n <li>\n OnIceComponentStateChanged: This event informs only about changes in the ICE connection state. Possible values are:\n <ul>\n <li>DISCONNECTED: No activity scheduled</li>\n <li>GATHERING: Gathering local candidates</li>\n <li>CONNECTING: Establishing connectivity</li>\n <li>CONNECTED: At least one working candidate pair</li>\n <li>READY: ICE concluded, candidate pair selection is now final</li>\n <li>FAILED: Connectivity checks have been completed, but media connection was not established</li>\n </ul>\n The transitions between states are covered in RFC5245.\n It could be said that it's 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.\n </li>\n <li>\n OnIceCandidate: 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.\n </li>\n <li>\n OnIceGatheringDone: Raised when the ICE harvesting process is completed. This means that all candidates have already been discovered.\n </li>\n <li>\n 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.\n </li>\n <li>\n OnDataChannelOpened: Raised when a data channel is open.\n </li>\n <li>\n OnDataChannelClosed: Raised when a data channel is closed.\n </li>\n </ul>\n </p>\n <p>\n 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.\n </p>\n <p>\n Flow control and congestion management 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 exploration 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 quality. 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 bandwidth 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 transcoder output will share a separate quality than the ones connected directly to the original stream.\n </p>\n <p>\n The default bandwidth range of the endpoint is 100kbps-500kbps, but it can be changed separately for input/output directions and for audio/video streams.\n <ul style='list-style-type:circle'>\n <li>\n Input bandwidth control mechanism: Configuration interval used to inform remote peer the range of bitrates that can be pushed into this WebRtcEndpoint object.\n <ul>\n <li>\n setMin/MaxVideoRecvBandwidth: sets Min/Max bitrate limits expected for received video stream.\n </li>\n <li>\n setMin/MaxAudioRecvBandwidth: sets Min/Max bitrate limits expected for received audio stream.\n </li>\n </ul>\n Max values are announced in the SDP, while min values are set to limit the lower value of REMB packages. It follows that min values will only have effect in peers that support this control mechanism, such as Chrome.\n </li>\n <li>\n Output bandwidth control mechanism: Configuration interval used to control bitrate of the output video stream sent to remote peer. It is important to keep in mind that pushed bitrate depends on network and remote peer capabilities. Remote peers can also announce bandwidth limitation in their SDPs (through the b=<modifier>:<value> tag). Kurento will always enforce bitrate limitations specified by the remote peer over internal configurations.\n <ul>\n <li>\n setMin/MaxVideoSendBandwidth: sets Min/Max bitrate limits for video sent to remote peer\n </li>\n <li>\n setMin/MaxAudioSendBandwidth: sets Min/Max bitrate limits for audio sent to remote peer.\n </li>\n </ul>\n </li>\n </ul>\n All bandwidth control parameters must be changed before the SDP negotiation takes place, and can't be changed afterwards.\n </p>\n <p>\n 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’ll 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:\n <ul>\n <li>\n Reliable or partially reliable delivery of sent messages\n </li>\n <li>\n In-order or out-of-order delivery of sent messages\n </li>\n </ul>\n 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.\n </p>\n <p>\n 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:\n <ul>\n <li>\n `label`: assigns a label to the DataChannel. This can help identify each possible channel separately.\n </li>\n <li>\n `ordered`: specifies if the DataChannel guarantees order, which is the default mode. If maxPacketLifetime and maxRetransmits have not been set, this enables reliable mode.\n </li>\n <li>\n `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.\n </li>\n <li>\n `maxRetransmits`: maximum number of retransmissions that are attempted in unreliable mode. This forces unreliable mode, even if “ordered” has been activated.\n </li>\n <li>\n `Protocol`: Name of the subprotocol used for data communication.\n </li>\n </ul>\n ", | ||
| "doc": "<p>\n Control interface for Kurento WebRTC endpoint.\n </p>\n <p>\n This endpoint is one side of a peer-to-peer WebRTC communication, being the other peer a WebRTC capable browser -using the RTCPeerConnection API-, a native WebRTC app or even another Kurento Media Server.\n </p>\n <p>\n In order to establish a WebRTC communication, peers engage in an SDP negotiation process, where one of the peers (the offerer) sends an offer, while the other peer (the offeree) responds with an answer. This endpoint can function in both situations\n <ul>\n <li>\n As offerer: The negotiation process is initiated by the media server\n <ul style='list-style-type:circle'>\n <li>KMS generates the SDP offer through the <code>generateOffer</code> method. This <i>offer</i> must then be sent to the remote peer (the offeree) through the signaling channel, for processing.</li>\n <li>The remote peer process the <i>offer</i>, and generates an <i>answer</i> to this <i>offer</i>. The <i>answer</i> is sent back to the media server.</li>\n <li>Upon receiving the <i>answer</i>, the endpoint must invoke the <code>processAnswer</code> method.</li>\n </ul>\n </li>\n <li>\n As offeree: The negotiation process is initiated by the remote peer\n <ul>\n <li>The remote peer, acting as offerer, generates an SDP <i>offer</i> and sends it to the WebRTC endpoint in Kurento.</li>\n <li>The endpoint will process the <i>offer</i> invoking the <code>processOffer</code> method. The result of this method will be a string, containing an SDP <i>answer</i>.</li>\n <li>The SDP <i>answer</i> must be sent back to the offerer, so it can be processed.</li>\n </ul>\n </li>\n </ul>\n </p>\n <p>\n 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\n <ul>\n <li>Discovers ICE candidates for itself, containing pairs of IPs and ports.</li>\n <li>ICE candidates are sent via the signaling channel as they are discovered, to the remote peer for probing.</li>\n <li>ICE connectivity checks are run as soon as the new candidate description, from the remote peer, is available.</li>\n </ul>\n 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 <code>gatherCandidates</code> 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 <code>IceCandidateFound</code>. It is important that the event listener is bound before invoking <code>gatherCandidates</code>, otherwise a suitable candidate might be lost, and connection might not be established.\n </p>\n <p>\n It's 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:\n <ul>\n <li>\n <code>IceComponentStateChange</code>: This event informs only about changes in the ICE connection state. Possible values are:\n <ul style='list-style-type:circle'>\n <li><code>DISCONNECTED</code>: No activity scheduled</li>\n <li><code>GATHERING</code>: Gathering local candidates</li>\n <li><code>CONNECTING</code>: Establishing connectivity</li>\n <li><code>CONNECTED</code>: At least one working candidate pair</li>\n <li><code>READY</code>: ICE concluded, candidate pair selection is now final</li>\n <li><code>FAILED</code>: Connectivity checks have been completed, but media connection was not established</li>\n </ul>\n The transitions between states are covered in RFC5245.\n It could be said that it's 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 <code>CONNECTED</code>, 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.\n </li>\n <li>\n <code>IceCandidateFound</code>: 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.\n </li>\n <li>\n <code>IceGatheringDone</code>: Raised when the ICE harvesting process is completed. This means that all candidates have already been discovered.\n </li>\n <li>\n <code>NewCandidatePairSelected</code>: 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.\n </li>\n <li>\n <code>DataChannelOpen</code>: Raised when a data channel is open.\n </li>\n <li>\n <code>DataChannelClose</code>: Raised when a data channel is closed.\n </li>\n </ul>\n </p>\n <p>\n 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.\n </p>\n <p>\n Flow control and congestion management 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 exploration 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 quality. 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 bandwidth 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 transcoder output will share a separate quality than the ones connected directly to the original stream.\n </p>\n <p>\n The default bandwidth range of the endpoint is 100kbps-500kbps, but it can be changed separately for input/output directions and for audio/video streams.\n <ul>\n <li>\n Input bandwidth control mechanism: Configuration interval used to inform remote peer the range of bitrates that can be pushed into this WebRtcEndpoint object.\n <ul style='list-style-type:circle'>\n <li>\n setMin/MaxVideoRecvBandwidth: sets Min/Max bitrate limits expected for received video stream.\n </li>\n <li>\n setMin/MaxAudioRecvBandwidth: sets Min/Max bitrate limits expected for received audio stream.\n </li>\n </ul>\n Max values are announced in the SDP, while min values are set to limit the lower value of REMB packages. It follows that min values will only have effect in peers that support this control mechanism, such as Chrome.\n </li>\n <li>\n Output bandwidth control mechanism: Configuration interval used to control bitrate of the output video stream sent to remote peer. It is important to keep in mind that pushed bitrate depends on network and remote peer capabilities. Remote peers can also announce bandwidth limitation in their SDPs (through the <code>b=<modifier>:<value></code> tag). Kurento will always enforce bitrate limitations specified by the remote peer over internal configurations.\n <ul style='list-style-type:circle'>\n <li>\n setMin/MaxVideoSendBandwidth: sets Min/Max bitrate limits for video sent to remote peer\n </li>\n </ul>\n </li>\n </ul>\n All bandwidth control parameters must be changed before the SDP negotiation takes place, and can't be changed afterwards.\n </p>\n <p>\n 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'll 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:\n <ul>\n <li>\n Reliable or partially reliable delivery of sent messages\n </li>\n <li>\n In-order or out-of-order delivery of sent messages\n </li>\n </ul>\n 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 <i>partially reliable</i> by specifying the maximum number of retransmissions or setting a time limit for retransmissions: the WebRTC stack will handle the acknowledgments and timeouts.\n </p>\n <p>\n 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:\n <ul>\n <li>\n <code>label</code>: assigns a label to the DataChannel. This can help identify each possible channel separately.\n </li>\n <li>\n <code>ordered</code>: specifies if the DataChannel guarantees order, which is the default mode. If maxPacketLifetime and maxRetransmits have not been set, this enables reliable mode.\n </li>\n <li>\n <code>maxPacketLifeTime</code>: The time window in milliseconds, during which transmissions and retransmissions may take place in unreliable mode. This forces unreliable mode, even if <code>ordered</code> has been activated.\n </li>\n <li>\n <code>maxRetransmits</code>: maximum number of retransmissions that are attempted in unreliable mode. This forces unreliable mode, even if <code>ordered</code> has been activated.\n </li>\n <li>\n <code>Protocol</code>: Name of the subprotocol used for data communication.\n </li>\n </ul>\n ", | ||
| "extends": "BaseRtpEndpoint", | ||
@@ -95,2 +95,9 @@ "constructor": { | ||
| "defaultValue": false | ||
| }, | ||
| { | ||
| "name": "certificateKeyType", | ||
| "doc": "Define the type of the certificate used in dtls", | ||
| "type": "CertificateKeyType", | ||
| "optional": true, | ||
| "defaultValue": "RSA" | ||
| } | ||
@@ -103,3 +110,3 @@ ], | ||
| "name": "stunServerAddress", | ||
| "doc": "Address of the STUN server (Only IP address are supported)", | ||
| "doc": "address of the STUN server (Only IP address are supported)", | ||
| "type": "String" | ||
@@ -109,3 +116,3 @@ }, | ||
| "name": "stunServerPort", | ||
| "doc": "Port of the STUN server", | ||
| "doc": "port of the STUN server", | ||
| "type": "int" | ||
@@ -115,3 +122,3 @@ }, | ||
| "name": "turnUrl", | ||
| "doc": "TURN server URL with this format: 'user:password@address:port(?transport=[udp|tcp|tls])'.\n'address' must be an IP (not a domain).\n'transport' is optional (UDP by default).", | ||
| "doc": "TURN server URL with this format: <code>user:password@address:port(?transport=[udp|tcp|tls])</code>.</br><code>address</code> must be an IP (not a domain).</br><code>transport</code> is optional (UDP by default).", | ||
| "type": "String" | ||
@@ -121,3 +128,3 @@ }, | ||
| "name": "ICECandidatePairs", | ||
| "doc": "The ICE candidate pair (local and remote candidates) used by the ice library for each stream.", | ||
| "doc": "the ICE candidate pair (local and remote candidates) used by the ice library for each stream.", | ||
| "type": "IceCandidatePair[]", | ||
@@ -128,3 +135,3 @@ "readOnly": true | ||
| "name": "IceConnectionState", | ||
| "doc": "The ICE connection state for all the connections.", | ||
| "doc": "the ICE connection state for all the connections.", | ||
| "type": "IceConnection[]", | ||
@@ -138,3 +145,3 @@ "readOnly": true | ||
| "name": "gatherCandidates", | ||
| "doc": "Start the gathering of ICE candidates.\nIt must be called after SdpEndpoint::generateOffer or SdpEndpoint::processOffer for Trickle ICE. If invoked before generating or processing an SDP offer, the candidates gathered will be added to the SDP processed." | ||
| "doc": "Start the gathering of ICE candidates.</br>It must be called after SdpEndpoint::generateOffer or SdpEndpoint::processOffer for Trickle ICE. If invoked before generating or processing an SDP offer, the candidates gathered will be added to the SDP processed." | ||
| }, | ||
@@ -170,3 +177,3 @@ { | ||
| "name": "maxPacketLifeTime", | ||
| "doc": "The time window (in milliseconds) during which transmissions and retransmissions may take place in unreliable mode.\n\n .. note:: This forces unreliable mode, even if ordered has been activated", | ||
| "doc": "The time window (in milliseconds) during which transmissions and retransmissions may take place in unreliable mode.</br>\n .. note:: This forces unreliable mode, even if <code>ordered</code> has been activated", | ||
| "type": "int", | ||
@@ -178,3 +185,3 @@ "optional": true, | ||
| "name": "maxRetransmits", | ||
| "doc": "maximum number of retransmissions that are attempted in unreliable mode.\n\n .. note:: This forces unreliable mode, even if ordered has been activated", | ||
| "doc": "maximum number of retransmissions that are attempted in unreliable mode.</br>\n .. note:: This forces unreliable mode, even if <code>ordered</code> has been activated", | ||
| "type": "int", | ||
@@ -351,2 +358,9 @@ "optional": true, | ||
| "defaultValue": false | ||
| }, | ||
| { | ||
| "name": "networkCache", | ||
| "doc": "When using rtsp sources. Amount of ms to buffer", | ||
| "type": "int", | ||
| "optional": true, | ||
| "defaultValue": 2000 | ||
| } | ||
@@ -667,2 +681,11 @@ ], | ||
| { | ||
| "typeFormat": "ENUM", | ||
| "values": [ | ||
| "RSA", | ||
| "ECDSA" | ||
| ], | ||
| "name": "CertificateKeyType", | ||
| "doc": "." | ||
| }, | ||
| { | ||
| "typeFormat": "REGISTER", | ||
@@ -703,6 +726,7 @@ "properties": [ | ||
| "MP4_AUDIO_ONLY", | ||
| "JPEG_VIDEO_ONLY", | ||
| "KURENTO_SPLIT_RECORDER" | ||
| ], | ||
| "name": "MediaProfileSpecType", | ||
| "doc": "Media Profile.\n\nCurrently WEBM and MP4 are supported." | ||
| "doc": "Media Profile.\n\nCurrently WEBM, MP4 and JPEG are supported." | ||
| }, | ||
@@ -751,3 +775,3 @@ { | ||
| "name": "OnIceCandidate", | ||
| "doc": "@deprecated\nNotifies a new local candidate. These candidates should be sent to the remote peer, to complete the ICE negotiation process." | ||
| "doc": "@deprecated</br>Notifies a new local candidate. These candidates should be sent to the remote peer, to complete the ICE negotiation process." | ||
| }, | ||
@@ -770,3 +794,3 @@ { | ||
| "name": "OnIceGatheringDone", | ||
| "doc": "@deprecated\nEvent fired when al ICE candidates have been gathered." | ||
| "doc": "@deprecated</br>Event fired when al ICE candidates have been gathered." | ||
| }, | ||
@@ -799,3 +823,3 @@ { | ||
| "name": "OnIceComponentStateChanged", | ||
| "doc": "@deprecated\nEvent fired when and ICE component state changes. See :rom:cls:`IceComponentState` for a list of possible states." | ||
| "doc": "@deprecated</br>Event fired when and ICE component state changes. See :rom:cls:`IceComponentState` for a list of possible states." | ||
| }, | ||
@@ -834,3 +858,3 @@ { | ||
| "name": "OnDataChannelOpened", | ||
| "doc": "@deprecated\nEvent fired when a new data channel is created." | ||
| "doc": "@deprecated</br>Event fired when a new data channel is created." | ||
| }, | ||
@@ -859,3 +883,3 @@ { | ||
| "name": "OnDataChannelClosed", | ||
| "doc": "@deprecated\nEvent fired when a data channel is closed." | ||
| "doc": "@deprecated</br>Event fired when a data channel is closed." | ||
| }, | ||
@@ -914,3 +938,3 @@ { | ||
| "name": "Paused", | ||
| "doc": "Fired when the recorder goes to pause state" | ||
| "doc": "@deprecated</br>Fired when the recorder goes to pause state" | ||
| }, | ||
@@ -921,5 +945,5 @@ { | ||
| "name": "Stopped", | ||
| "doc": "Fired when the recorder has been stopped and all the media has been written to storage." | ||
| "doc": "@deprecated</br>Fired when the recorder has been stopped and all the media has been written to storage." | ||
| } | ||
| ] | ||
| } |
No alert changes
Improved metrics
- Total package byte prevSize
- increased by2.36%
188311
- Number of package files
- increased by3.33%
31
- Lines of code
- increased by3.07%
4131
No dependency changes