System and method of authenticating a live video stream

A method of authenticating a video streaming transmission comprising generating a secure token at an application server, providing the secure token to a user device, receiving the secure token at a media server with a publish request from the user device, transmitting the secure token to the application server for authentication, and authenticating the secure token. The publish request from the user device is enabled if the secure token is authenticated by the application server. The connection between the media server and the user device is terminated if the secure token fails to authenticate.

FIELD OF THE INVENTION

The present disclosure generally relates to video streaming. More specifically, the present disclosure relates to a one-to-all video streaming authentication protocol.

BACKGROUND

Recent trends in social media applications are moving to expand a user's ability to share content—including live video streaming—with a wide network of people. Users can rely on a wide range of increasingly sophisticated mobile and handheld devices to capture live video. Users are searching for a reliable means to instantaneously share the video they capture with their family, friends, wider social networks, or even the public in general.

Existing content-sharing applications or programs have had difficulty fully enabling the sharing of content or providing sufficient functionality to enable quick and easy sharing of content. One reason that full sharing has proven difficult is that video streaming is computationally expensive and requires careful management in a mobile-to-mobile context.

Video streaming applications also rely on underlying protocols which can be difficult to authenticate and present their own set of vulnerabilities. For example, the unsecured endpoints of a video stream can be easily exploited by malicious scripts to drive up server costs or to execute a denial of service attack

SUMMARY OF THE DISCLOSURE

The present disclosure is directed to a method of authenticating a live video stream transmission which obviates many of the deficiencies cited above. The present disclosure is generally directed to an authentication protocol to be used during initiation of one-to-all or one-to-many live video streaming transmissions. The present disclosure provides a method of authenticating a video streaming transmission comprising generating a secure token at an application server, providing the secure token to a user device, receiving the secure token at a media server with a publish command from the user device, transmitting the secure token to the application server for authentication, and authenticating the secure token. The publish command from the user device is enabled if the secure token is authenticated by the application server. The connection between the media server and the user device is terminated if the secure token fails to authenticate.

In some embodiments of the present disclosure, a method is provided for transmitting packetized video data to a media server, the method including the steps of: receiving, at an application server, a request from a user device to transmit packetized video data to a media server; transmitting an endpoint from the application server to the user device; establishing a TCP/IP connection between the user device and a media server; enabled the user device to transmit packetized video data to the media server; transmitting a secure token with the endpoint from the application server to the user device; transmitting, during the step of establishing a TCP/IP connection, the secure token from the user device to the media server; transmitting the secure token from the media server to the application server for authentication; authenticating by the application server the secure token before the step of enabling the user device to transmit packetized video data.

In some embodiments of the present disclosure, a method is provided for establishing a connection for the transmission of packetized video data, including the steps of: receiving at an application server an endpoint request from a user device; transmitting from the application server to the user device an endpoint and a secure token; receiving at a media server a publish command from the user device; and enabling the user device to transmit packetized video data to the media server; inserting the secure token into the playname field of the publish command of the user device; and authenticating, at the application server, the secure token prior to enabling the user device to transmit packetized video data.

DETAILED DESCRIPTION

The present disclosure provides systems and methods of authenticating live video streams such as the non-permanent sharing of live streamed video content. The present disclosure provides a system for the non-permanent sharing of live streamed video content which allows a user to simultaneously stream video content and save video content to an internal user device memory or a cloud system memory. Further, the present disclosure addresses vulnerabilities in existing live streaming protocols, such as unsecured endpoints, by providing a secure means of live streaming and authentication. The present disclosure may reasonably be applied to other fields and endeavors with equal success.

FIG. 1is a schematic diagram of a live video streaming system100in accordance with some embodiments of the present disclosure. An image101is captured in video format by user device103(also called a client device103in protocol descriptions below) and displayed on screen105of the user device103. In some embodiments, the user device103may be a smart phone, tablet, laptop, or similar mobile computing device.

As the video is captured by user device103, it is transmitted from user device103to an elastic load balancing (ELB) media server111, which comprises a plurality of media servers. These media servers are designated “media server1” “media server2” and “media server3” inFIG. 1but in some embodiments may include any number n of media servers. The video is transmitted from user device103to ELB media server111using a PUBLISH function of the Real Time Messaging Protocol (RTMP), discussed further in reference toFIGS. 2, 3, and 4below. In some embodiments, the RTMP used to transmit video from user device103to ELB media server111has been modified in accordance with the description below and with reference toFIG. 3.

In some embodiments, the video captured by user device103is also transmitted to a cloud-based storage device109or other memory device remote from user device103. In some embodiments, the video captured by user device103is stored on a memory device107internal to the user device103.

ELB media server111receives packetized video segments from user device103and performs the necessary conversions to broadcast the video. Video content received at ELB media server111is distributed using HTTP Live Streaming (HLS) protocol or RTMP. For video distribution using HLS protocol, individual .ts file segments, including the .m3u8 envelope, are transmitted to and stored in object storage server115. Video is then transmitted, or streamed, to a consumer user device117.

For video distribution using RTMP, video is transferred to an ELB RTMP Demultiplexer113comprising a plurality of RTMP streamers. These RTMP streamers are designated “RTMP streamer1” “RTMP streamer2” and “RTMP streamer3” inFIG. 1, but in some embodiments may include any number n of RTMP streamers. Each of the plurality of RTMP Streamers of the ELB RTMP Demultiplexer113is configured to use internal in-memory buffers to broadcast the video to a plurality of consumer user devices117using a single in-memory representation of the video stream. ELB RTMP Demultiplexer113is further configured to react to variable transfer bitrates of the video stream between ELB RTMP Demultiplexer113and each of the plurality of consumer user devices117.

Thus as illustrated inFIG. 1the live video streaming system100enables a one-to-many streaming of live video from a user device103to a plurality of consumer user devices117. Live video streaming system100is configured to use a plurality of networks to distribute the stream of live video.

FIG. 2Ais a flow diagram of a method200of initiating a live stream transmission between the client device103and media server111. Method200is largely modeled on Real Time Messaging Protocol (RTMP). However, method200provides secured endpoints during live video stream transmission to address vulnerabilities associated with unsecured endpoints as discussed above. Authentication is provided in method200by an application server201. In some embodiments, application server201is a third party server which is not controlled or operated by the same entity as the media server111.

Method200begins with client device103transmitting a request at step203to the application server201for a Uniform Resource Locator (URL). Application server201responds at step205to the client device103by publishing a URL with an embedded security token. Collectively, steps203and205form the request and publish URL phase207of method200.

In some embodiments, such as those involving the iOS operating system, the client device103request for a URL is sent to the application server201when the application is opened on the client device103. This is known as “pre-fetch,” because the client device103will receive the URL necessary to transmit a live video stream before such transmission is initiated by the user. In other embodiments, such as those using an android operating system, the client device103request for a URL is sent to the application server201when a user attempts to initiate live video stream transmission at the client device103.

The security token embedded in the URL transmitted from application server201to client device103is a cryptographically-secure token. The security token may, for example, be generated using a pseudo-random number generator, an encryption algorithm such as a hash-based message authentication code secure hash algorithm (HMAC-SHA), another hash-based encryption algorithm, a non-hash-based encryption algorithm (e.g., a message authentication code algorithm), or any combination thereof. Application server201stores a copy of the security token for later authentication.

In some embodiments, application server201is a third party server provided by a third party authentication service. In some embodiments, the third party authentication service is enabled to perform dynamic decisionmaking when creating, transmitting, and authenticating a security token. The third party authentication service is thus not locked in to a single means of security token generation and evaluation.

In some embodiments, application server201and media server111are commonly operated. The common operator may be enabled to perform dynamic decisionmaking when creating, transmitting, and authenticating a security token, and is thus not locked in to a single means of security token generation and evaluation.

Following the request and publish URL phase207, method200continues with the handshake and connection phase217. This phase217comprises a handshake between client device103and media server111, followed by the establishment of a connection between client device103and media server111. The handshake and connection phase217is illustrated in general terms inFIG. 2A, and is shown in greater detail inFIG. 2B, described below.

At step209, client device103initiates the RTMP handshake protocol. Media server111replies to the handshake initiation at step211, again in accordance with the RTMP handshake protocol. Once the handshake is completed, the client device103requests a connection at step213and the media server111establishes the connection at step215.

FIG. 2Billustrates the handshake and connection phase217in greater detail. Specifically, handshake and connection phase217begins with client device103initiating a handshake with media server111at step209. Media server111replies to the handshake at step211. RTMP is followed to establish a connection between client device103and media server111. Client device103sends a command message to connect to the media server111at step301. At steps303and305, the media server responds with a window acknowledge size message to inform the client device103of the window size to use between sending acknowledgments, and with a set peer bandwidth message which limits the output bandwidth of client device103. Upon receipt of the set peer bandwidth message, the client device limits its output bandwidth by limiting the amount of sent but unacknowledged data to the indicated window size.

At step307the client device103returns a window acknowledge size message to media server111. At step309, the media server111notifies the client device103of a user control event, the initiation of streaming which is controlled by the user of client device103. At step311the media server111notifies client device103of the result of previous command message at step301, which is the creation of a connection between media server111and client device103.

At step313the client device103sends a command message to create a stream, and at step315the media server111responds with a stream creation. Once the handshake and connection phase217is completed, method200continues to the publish phase231.

Returning toFIG. 2A, the publish phase231begins at step219with client device103sending a publish request to media server111. This publish request includes the security token received from application server201. At step221, the media server extracts the security token and then at step223the security token is sent to the application server as part of a security token authentication request. The application server attempts to authenticate the security token at step225.

In some embodiments, authenticating the security token comprises comparing the security token received from the media server at step223to the security token which was embedded in the URL transmitted to the client device103at step205. As noted above, the security token transmitted to the client device103is generated using a variety of methods and is stored by the application server201for later authentication purposes.

If the security token received from the media server111at step223is authenticated, then a message to that effect is sent to media server111. In some embodiments, the security token received from the media server at step223is authenticated if it matches the security token which was embedded in the URL transmitted to the client device103at step205. In other embodiments, application server201replicates the token-generation process to authenticate the security token received from the media server at step223. In still further embodiments various cryptographic techniques are used to authenticate the security token received from the media server at step223.

With an authenticated security token media server111will proceed with the publish phase231. However, if the security token received from the media server at step223does not match the security token which was embedded in the URL transmitted to the client device103at step205, then the security token has failed authentication and a message to that effect is sent to media server111. With an unauthenticated security token media server111will not proceed with the publish phase231and will instead break the previously established connection with client device103.

In some embodiments, authenticating the security token comprises comparing the security token received at step223with the security token transmitted at step205as well as an evaluation of external factors (i.e. factors not directly associated with the security token itself). Such factors may include the IP address of the client device103, the physical location of the client device103, and the streaming rate of client device103. In embodiments where external factors are considered during authentication, the application server201may be enabled to perform dynamic decisionmaking allowing the application server201to adjust authentication factors and parameters without manual intervention and server updates.

Based on the outcome of security token authentication at application server201, media server111at step227sends a publish reply to client device103. The publish reply either enables further steps in the publication phase if the security token was authenticated or severs the connection if the security token failed authentication. Once the publish reply is received, the client device103will begin to publish data at step229.

Publish phase231is illustrated in greater detail inFIG. 2C. InFIG. 2Cthe publish request sent from the client device103to the media server111at step219is illustrated as a publish command message at step401. In some embodiments, the secure token is transmitted from the client device103to the media server111in the “playname” field of the publish command message at step401.

Following the authentication reply from application server201to media server111at step225, the media server111notifies client device103of a user controlled event, the initiation of streaming (StreamBegin) at step403. Upon initiation of streaming, the client device103sends three successive messages to the media server111at steps405,407, and409to provide the media server111with metadata, audio data, and set chunk size, respectively. Media server111responds with a result command message at step411. At step413, client device103begins to transmit video data as packetized data such as packetized live video steaming to the media server111, and this transmission of video data continues until the user ceases transmission.

FIG. 3Ais a flow diagram of a method500of initiating a video stream transmission from a client device103. The method500begins at step501. At step503the client device publishes a URL request to the application server201, and the application server201responds at step505with a URL embedded with a security token. Client device103then initiates a handshake with media server111at step507, and the media server111replies to the handshake at step509. Client device103requests a TCP/IP connection with media server111at step511. At step513the connection is established. Upon user initiation, the client device103at step515transmits a publish request to media server111. The publish request includes the security token. In some embodiments, the publish request is a RTMP publish command and the security token is embedded in the “playname” field of the command message. At step517the client device103receives a reply from the media server111to the publish request. The reply either enables the client device103for publishing or denies the request and severs the connection with the client device103. If enabled, at step519the client device103publishes video data to media server111. The method500ends at step521when the user ceases publishing video data or the connection is interrupted or severed.

FIG. 3Bis a flow diagram of a method600of receiving a video stream transmission at a media server111. Method600begins at step601. At step603, the media server111receives a handshake initiation from client device103, and at step605the media server111replies to the handshake initiation. The media server111then receives a connection request from the client device at step607. The media server111establishes the connection at step609, and subsequently receives a publish request from the client device at step611. The publish request includes a security token. In some embodiments, the publish request is a RTMP publish command and the security token is embedded in the “playname” field of the command message. At step613the security token is extracted from the publish request, and at step615the security token is transmitted to the application server201for authentication. A reply to the authentication request is received from the application server201at step617, and this reply either authenticates the security token or fails to authenticate the security token. If the security token is authenticated by the application server201, then media server111proceeds to step619and enables the client device103publish request. Once enabled, at step621the media server111receives published video data from the client device. If the security token is not authenticated by the application server201, then media server111proceeds to step623and denies the publish request of client device103. In some embodiments, media server then proceeds to step625and severs the TCP/IP connection with the client device103. Method600ends at step627.

FIG. 3Cis a flow diagram of a method700of facilitating a video stream transmission at an application server201. Method700begins at step701. At step703, the application server201receives a URL publish request from client device103. The application server responds by generating a security token at block705, embedding the security token in the URL and transmitting the URL with embedded security token to the client device103at step707, and storing the security token at step709. At step711the security token is received from media server111with an authentication request. At step713the application server201conducts authentication of the security token. In some embodiments, authenticating the security token comprises comparing the security token received from the media server at step711to the security token which was embedded in the URL transmitted to the client device103at step707. In some embodiments, authenticating the security token may additionally comprise evaluating various external factors and employing dynamic decisionmaking. At step715, application server201replies to the security token authentication request from media server111, either authenticating the security token or failing to authenticate the security token. Method700ends at step717.

The present disclosure provides numerous advantages over the prior art. Most notably, the present disclosure provides a system and method of streaming live video content from a mobile user device to a plurality of consumer user devices using multiple networks, variable bit transfer rates, protocols, and formats. The present disclosure further provides a method of authenticating live video streams to enhance security of the disclosed system. The present disclosure further provides a novel means of identifying available video streams for viewing based on location and/or proximity of users.

Perhaps most significantly, the present disclosure provides a method of authenticating a client device generated live video stream transmission which is able to employ dynamic decisionmaking during the authentication process. The authentication may be performed by a third party authentication service, which generates, transmits to the client device, and later authenticates a security token. The authenticating party may additionally use external variables to evaluate the security token for authentication. Thus the authentication of the security token is easily altered and not locked in to a prescribed method. This dynamic authentication allows for updates and changes as necessary to adapt to evolving threats such as malicious scripts or denial of service attacks.