Techniques to manage recordings for multimedia conference events
US-9705691-B2 · Jul 11, 2017 · US
US10348784B2 · US · B2
| Field | Value |
|---|---|
| Publication number | US-10348784-B2 |
| Application number | US-201715433636-A |
| Country | US |
| Kind code | B2 |
| Filing date | Feb 15, 2017 |
| Priority date | Feb 15, 2017 |
| Publication date | Jul 9, 2019 |
| Grant date | Jul 9, 2019 |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
A conferencing server is directly accessible from the public Internet and has a host transport address, which is a combination of a public IP address on the public Internet and an associated port. It comprises conference hosting logic for hosting at least one conference, in which media data is transmitted and received via the conferencing server between participant endpoints; media processing logic configured to process received media data of the conference for transmission in the conference; multiplexing control logic configured to determine a plurality of multiplexing tokens to be used by the participant endpoints; and demultiplexing logic configured to identify received multiplexing tokens in transport layer payload data of a sequence data packets received from the participant endpoints at the host transport address, and use the multiplexing tokens identified in the transport layer payload data to demultiplex the data packets for processing by the media processing logic.
Opening claim text (preview).
The invention claimed is: 1. A conferencing server configured to be directly accessible from the public Internet, the conferencing server comprising: a network interface having a host transport address, the host transport address being a combination of a public IP address on the public Internet and an associated port; conference hosting logic for hosting, at the conferencing server, at least one conference, in which media data is transmitted and received via the conferencing server between participant endpoints; media processing logic configured to process received media data of the conference for transmission in the conference; multiplexing control logic configured to manage a plurality of multiplexing tokens generated by the conferencing server to be used by the participant endpoints to identify the participant endpoints; and demultiplexing logic configured to identify received multiplexing tokens in transport layer payload data of a sequence of data packets received from the participant endpoints at the host transport address, and use the multiplexing tokens identified in the transport layer payload data to demultiplex the data packets for processing by the media processing logic. 2. The conferencing server according to claim 1 comprising: candidate gathering logic configured to determine a set of one or more candidate pairs for each of the participant endpoints, by exchanging network addresses between the conferencing server and that endpoint, wherein at least one candidate pair in the set is a multiplexed candidate pair comprising the host transport address and one of the multiplexing tokens uniquely selected for use by that endpoint; connectivity check logic configured to perform, for each of the participant endpoints, connectivity checks for at least one candidate pair in the set to determine whether it is valid; and candidate selection logic configured to select, for each participant endpoint in the conference, a candidate pair determined to be valid in the connectivity checks for that endpoint. 3. The conferencing server according to claim 2 , wherein connectivity checks are performed for only the multiplexed candidate pair. 4. The conferencing server according to claim 1 , wherein the media processing logic comprises audio mixing logic configured to generate a mixed audio stream for each participant endpoint in the hosted conference. 5. The conferencing server according to claim 1 , wherein the media processing logic comprises video switching logic configured to switch between different received video streams for each participant endpoint in the hosted conference. 6. The conferencing server according to claim 1 , wherein the multiplexing tokens are negotiated between the conferencing server and the participant endpoint via secure signaling channels. 7. The conferencing server according to claim 1 , wherein the multiplexing control logic is configured to generate the multiplexing tokens for the endpoints. 8. The conferencing server according to claim 1 , wherein the demultiplexing logic is configured to provide media data received from each of the participating endpoints to one or more media processing components of the media processing logic associated with that endpoint. 9. The conferencing server according to claim 8 , wherein the demultiplexing logic is configured to demultiplex UDP datagrams received from each of the plurality of participant endpoints at the host transport address by: identifying a received multiplexing token in the transport layer payload data of each of the UDP datagrams received from that endpoint, thereby identifying that endpoint as a source of that datagram, and providing media data of that UDP packet to the one or more media processing components associated with the identified endpoint. 10. The conferencing server according to claim 9 , wherein the media processing logic is configured to demultiplex the UDP datagrams without using a source transport address indicated with the UDP datagrams. 11. The conferencing server according to claim 8 , wherein the demultiplexing logic is configured to demultiplex TCP packets received from each of the plurality of participant endpoints at the host transport address by: identifying a multiplexing token received at the host transport address from that endpoint, as transport layer payload data, in association with an incoming TCP connection request from that endpoint, thereby identifying that endpoint as a source of that TCP connection request, accepting the incoming TCP connection request, thereby establishing a TCP connection, and associating the TCP connection with the one or more media processing functions associated with the identified endpoint, thereby providing a path for media data from the endpoint to the media processing components via the TCP connection. 12. The conferencing server according to claim 11 , wherein the demultiplexing logic is configured to accept a new incoming connection request from that endpoint when received in association with a matching multiplexing token, thereby establishing a new TCP connection, and associate the new TCP connection with the one or more media processing components, thereby providing a new path from the endpoint to the media processing components via the new TCP connection. 13. The conferencing server according to claim 12 , wherein the TCP connection persists when the new TCP connection is established, thereby simultaneously providing two paths from the endpoint to the one or more media processing components. 14. The conferencing server according to claim 12 , wherein the TCP connection is accepted and the multiplexing token is identified using the AcceptEx function, the multiplexing token being received in association with the TCP request in that it is received in an initial block of data read by the AcceptEx function. 15. The conferencing server according to claim 1 , wherein the network interface has a first transport address used to receive TCP packets and a second transport address used to receive UDP datagrams. 16. The conferencing server according to claim 1 , wherein a single TCP socket is bound to a port of the first transport address at the conferencing server, and a single UDP socket is bound to a port of the second transport address at the conferencing server, and a single I/O completion port of the conferencing server is bound to both the TCP and UDP sockets. 17. The conferencing server according to claim 16 , wherein the demultiplexing logic comprises a plurality of processor cores, each of which is configured to serve the I/O completion port. 18. The conferencing server according to claim 17 , wherein each of the processor cores is configured to execute at least two threads, each of which is configured to serve the I/O completion port. 19. A method of hosting, at a conferencing server having a host transport address, at least one conference, in which media data is transmitted and received via the conferencing server between participant endpoints, the host transport address being a combination of a public IP address on the public Internet and an associated port, such that the conferencing server is directly accessible from the public Internet, the method comprising, at the conferencing server: managing a plurality of multiplexing tokens generated by the conferencing server to be used by the participant endpoints to identify the participant endpoints; identifying received multiplexing tokens in transport layer payload data of a sequence of data packets received from the participant endpoints at th
for a higher-layer protocol, e.g. for session initiation protocol [SIP] · CPC title
between local and global IP addresses · CPC title
with floor control · CPC title
over a relay server, e.g. traversal using relay for network address translation [TURN] · CPC title
Session establishment or de-establishment · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.