@webex/web-client-media-engine
Advanced tools
@webex/web-client-media-engine - npm Package Compare versions
Comparing version 3.5.1 to 3.5.2
@@ -6,2 +6,3 @@ import { LocalStream, ConnectionState } from '@webex/webrtc-core'; | ||
| import { LogData } from '@webex/rtcstats'; | ||
| export { LogData } from '@webex/rtcstats'; | ||
| import TypedEmitter, { EventMap } from 'typed-emitter'; | ||
@@ -198,2 +199,3 @@ import { TypedEvent } from '@webex/ts-events'; | ||
| declare type MetricsCallback = (logData: LogData) => void; | ||
| declare enum MultistreamConnectionEventNames { | ||
@@ -200,0 +202,0 @@ VideoSourceCountUpdate = "video-source-count-update", |
| { | ||
| "name": "@webex/web-client-media-engine", | ||
| "version": "3.5.1", | ||
| "version": "3.5.2", | ||
| "description": "Web Client Media Engine is common web code for interacting with the multistream media server.", | ||
@@ -58,3 +58,3 @@ "source": "src/index.ts", | ||
| "@webex/json-multistream": "^2.1.1", | ||
| "@webex/rtcstats": "^1.0.2", | ||
| "@webex/rtcstats": "^1.1.0", | ||
| "@webex/ts-events": "^1.0.1", | ||
@@ -61,0 +61,0 @@ "@webex/ts-sdp": "1.5.0", |
@@ -6,2 +6,3 @@ # Web Client Media Engine (WCME) | ||
|  | ||
| _UML diagram generated with [tplant](https://github.com/bafolts/tplant)._ | ||
@@ -29,7 +30,9 @@ ## Setup | ||
| const localAudioTrack = createMicrophoneTrack(); | ||
| multistreamConnection.publishTrack(localAudioTrack); | ||
| const audioSendSlot = multistreamConnection.createSendSlot(MediaType.AudioMain); | ||
| const localAudioStream = createMicrophoneStream(LocalMicrophoneStream); | ||
| audioSendSlot.publishStream(localAudioStream); | ||
| const localVideoTrack = createCameraTrack(); | ||
| multistreamConnection.publishTrack(localVideoTrack); | ||
| const videoSendSlot = multistreamConnection.createSendSlot(MediaType.VideoMain); | ||
| const localVideoStream = createCameraStream(LocalCameraStream); | ||
| videoSendSlot.publishStream(localVideoStream); | ||
| ``` | ||
@@ -107,18 +110,26 @@ | ||
| `MultistreamConnection` handles all the SDP manipulation required to accomplish the above for both the offer and the answer. It also performs additional preprocessing on the offer such as injecting content types and JMP attributes. | ||
| `MultistreamConnection` handles all the SDP manipulation required to accomplish the above for both the offer and the answer. It also performs additional preprocessing on the offer such as injecting content types and JMP attributes. All of this is handled by the appropriate SDP "mungers" (`IngressSdpMunger` and `EgressSdpMunger`), which are called before setting the local offer, sending the offer to the remote server, and setting the remote answer. | ||
| ## Transceivers | ||
| ## Transceivers and Slots | ||
| In WebRTC, RTCRtpTransceivers represent a pairing of send and receive SRTP streams between the client and server. WCME defines two classes of transceivers: `SendOnlyTransceiver` and `RecvOnlyTransceiver`. Each `MediaType` (`VideoMain`, `AudioMain`, `VideoSlides`, or `AudioSlides`) can only have one `SendOnlyTransceiver` but may have multiple `RecvOnlyTransceiver`s. `MultistreamConnection` maintains a list of all transceivers in a connection per `MediaType`. | ||
| Although `SendOnlyTransceiver`s are only used for sending, its underlying RTCRtpTransceiver direction is set to "sendrecv" in order to make it compatible with Homer. Each `SendOnlyTransceiver` maintains the state of the sending track -- whether or not it is published, whether or not it has been requested by a remote peer -- as well as handles replacing the existing track with a new one (e.g. when switching camera devices). | ||
| Although `SendOnlyTransceiver`s are only used for sending, its underlying RTCRtpTransceiver direction is set to "sendrecv" in order to make it compatible with Homer. Each `SendOnlyTransceiver` maintains the state of the sending stream -- whether or not it is published, whether or not it has been requested by a remote peer -- as well as handles replacing the existing stream with a new one (e.g. when switching camera devices). | ||
| `RecvOnlyTransceiver`s maintain the state of receiving tracks. Each `RecvOnlyTransceiver` is associated with a single `ReceiveSlot` (described below). | ||
| Likewise, `RecvOnlyTransceiver`s maintain the state of receiving streams. | ||
| ## ReceiveSlot | ||
| Clients should never have to interact with transceivers directly. Instead, all interactions with transceivers are handled via "slots". Each `SendOnlyTransceiver` is associated with a single `SendSlot`, while each `RecvOnlyTransceiver` is associated with a single `ReceiveSlot`. | ||
| WebRTC clients need tracks to be able to receive remote media, but creating a track for every remote participant's media would result in a huge SDP, and would require that the SDP was updated every time a client joined or left the session. So instead of allocating an RTCRtpReceiver for every remote participant, the receivers are treated as "slots" on which a remote participant (CSI) can be requested. `ReceiveSlot`s have an ID (which is the MID of the corresponding mline), and media is requested via JMP using these IDs. For example, if a client wants to receive the 3 most active speakers' audio, then it needs to create only 3 main audio receive slots, even if there are 25 participants in the meeting. | ||
| ### Receive Slots | ||
| The media received on a `ReceiveSlot` can change over time, depending on the policy requested on that slot and/or future media requests on that slot. `Source Indication` messages are used by the server to notify the client which CSI is being received on a `ReceiveSlot` at a given time. | ||
| WebRTC clients need to be able to receive remote media, but creating a stream for every remote participant's media would result in a huge SDP, and would require that the SDP was updated every time a client joined or left the session. So instead of allocating an RTCRtpReceiver for every remote participant, the receivers are treated as "slots" on which a remote participant (CSI) can be requested. `ReceiveSlot`s have an ID (which is the MID of the corresponding mline), and media is requested via JMP using these IDs. For example, if a client wants to receive the 3 most active speakers' audio, then it needs to create only 3 main audio receive slots, even if there are 25 participants in the meeting. | ||
| The media received on a `ReceiveSlot` can change over time, depending on the policy requested on that slot and/or future media requests on that slot. `sourceAdvertisement` messages are used by the server to notify the client which CSI is being received on a `ReceiveSlot` at a given time. | ||
| ### Send Slots | ||
| Similarly, send slots are used to handle sending local media. | ||
| By default, all `SendOnlyTransceiver`s are inactive (that is, the direction in the SDP offer is set to "inactive") until a `SendSlot` is created, during which the transceiver can be activated (the direction set to "sendrecv"). Only one `SendSlot` per media type should be created at a time, and `SendSlot`s can be activated or deactivated on the fly. | ||
| ## Requesting Media | ||
@@ -132,3 +143,3 @@ | ||
| The `MediaRequest` object is an abstraction on the JMP SCR object, and allows crafting different combinations of policies and `ReceiveSlot`s to achieve different behaviors. A `MediaRequest` consists of: | ||
| The `MediaRequest` object is an abstraction on the JMP media request object, and allows crafting different combinations of policies and `ReceiveSlot`s to achieve different behaviors. A `MediaRequest` consists of: | ||
@@ -139,3 +150,3 @@ - Policy | ||
| Details for these fields are the same as they are for the JMP SCR. Information can be found [here](https://confluence-eng-gpk2.cisco.com/conf/pages/viewpage.action?spaceKey=WMT&title=JMP+-+Json+Multistream+Protocol). | ||
| Details for these fields are the same as they are for the JMP media request. Information can be found [here](https://confluence-eng-gpk2.cisco.com/conf/pages/viewpage.action?spaceKey=WMT&title=JMP+-+Json+Multistream+Protocol). | ||
@@ -170,3 +181,3 @@ ### Examples | ||
| ## Utilities | ||
| ## Utilities and Other Exports | ||
@@ -178,2 +189,4 @@ WCME also defines several utility files with exported functions that may be useful in both WCME and in other code: | ||
| In addition to WCME exports, all necessary imports from `webrtc-core` and `json-multistream` are also re-exported for your convenience, so they can be used in other code without the need to import from those repositories separately. | ||
| ## Logging | ||
@@ -191,1 +204,3 @@ | ||
| ``` | ||
| Loggers from `webrtc-core` and `json-multistream` are also re-exported if you want to handle logs from those repositories separately. |
Sorry, the diff of this file is too big to display
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is too big to display
Sorry, the diff of this file is not supported yet
New alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Fixed alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Improved metrics
- Total package byte prevSize
- increased by1.44%
3134608
- Lines of code
- increased by1.06%
27774
- Number of lines in readme file
- increased by8.15%
199
Dependency changes
Updated@webex/rtcstats@^1.1.0