Overview of Technical Implementation

[njsfield]

Overview

This is an overview of the technical journeys of our three users, this is still a working progress so please feel free to submit your thoughts and feedback to further develop this.

(For visual aid, please refer to the wireframe examples provided in this repository.)

This implementation assumes these three Users;

• Mentor (user who initiates a new session and starts a live stream from their webcam. They can also see and partake in the text based messaging channel).
• Student (user who can partake in the text based chat room, by submitting messages that display their name next to it).
• Moderator (a Student who can view the Mentors live video Stream in a separate browser window as well as partaking in the text based chat room).

Mentor Journey

1. The Mentor first visits the home route at https://livepeers.com
2. On this route (/) the server checks to see if the request contains a cookie. On the Mentors first visit, no cookie is present, so…
3. The server responds by serving the create.html page, with the title Create New Session containing a form requesting the following information; Username (the username to be checked against a database (which will be a fake check for this first sprint)), Password (also fake-checked for this first sprint) and Session Name (the name that the Mentor would like to call the new live session, e.g; ‘Web RTC Workshop’- the naming of the live session that could later be stored in a database (for a future sprint, alongside other useful session information if a user would like to see historical information about live sessions).
4. The user submits this form as POST request to the route https://livepeers.com/createsession
5. The server then checks to make sure the Username and Password are correct (again, a fake check for this sprint)/
6. The server creates a unique session name (e.g ‘EFGHI’), and secret four digit pin (e.g. 6789) and stores it in a session data object in the server with the following information; {SID: EFGHI, PIN: 6789}
7. The server then creates a new Endpoint ID for the Mentor (which is a unique ID number, e.g 123), and adds a row to the Endpoints data object stored in the server; e.g. {EP_ID: 123, MESSAGES [], NAME: JOHN, PERMISSIONS: [‘CHAT’,’AV’]}. (Note: the PERMISSIONS field determines what role the endpoint has, so a Mentor will have both ‘CHAT’ and ‘AV’ permissions, meaning they can contribute to text message chats and view the live stream.)
8. The server then creates a Cookie and sets it to the Mentors browser, this cookie contains the session ID, name, and PIN.
9. The server redirects the Mentors browser to the home route (/).
10. On calling the home route, the server checks the cookie of the browser…
11. Which now contains the above information, so the server then responds with a mentor.html page that contains the following content; a link to the live session to share to the students (e.g. https://livepeers.com?sessionid=EFGHI), the PIN Code to also share to students who would like to view the Mentors video stream, a button displaying the number of currently active moderators and students (Note: on click, the Mentor is presented with more detailed information about the session’s current Moderators and Students), a text message area (containing all text messages from Students/Moderators), a text input box to send a text message, and a button to then end the live session.
12. The Mentors browser then begins polling to the server (regularly sending requests to the server to ask for new text messages, and receive/send RTCPeerConnection messages)

Student Journey (made possible after a session has been created by a Mentor)

1. After receiving the link from a Mentor, the student then visits the link in their browser, e.g; https://livepeers.com?sessionid=EFGHI
2. The server responds by serving the student.html page
3. student.html contains a title that displays the name of the session, a form with single input field labelled ’name’, and a button to enter the session.
4. The student then enters their name and clicks the button to enter the session.
5. At this point, instead of redirection, an XMLHttpRequest is submitted to the /messages route of the server containing the JOIN_CHAT method, session ID and users name, e.g; {MESSAGE: JOIN_CHAT’, SID: 12345, NAME: Tim'}
6. The server then creates a new Endpoint ID for the student (again, a unique ID number, e.g 432), and adds a row to the Endpoints data object stored in the server; e.g. {EP_ID: 432, MESSAGES [], NAME: TIM, PERMISSIONS: ‘CHAT’}.
7. The server then replies to the student’s XMLHttpRequest with this message: {MESSAGE: 'JOINED_CHAT', EP_ID: 432}.
8. The student’s browser then saves the EP_ID in their local data object (to define their EP_ID used as the ‘from’ field when sending text messages).
9. The student’s browser then begins polling to the server (regularly sending requests to the server with their EP_ID to ask for new messages).
10. On the students browser, several DOM manipulation changes occur so that the initial form is hidden, and the following content is displayed; a text message area displaying the latest messages from other Students, Moderators and the Mentor, an input element to write and submit a message, a button to submit that message, a button to Request Live Stream from Mentor, and a button to leave the chat.
11. When the student types a message (e.g 'Hello') and clicks the button to submit, a message is dispatched to the server (at the /messages route) via XMLHttpRequest containing the method ‘SEND_MESSAGE’, session ID, from (the EP_ID) to (SYSTEM), and message. e.g; {MESSAGE: 'SEND_MESSAGE', SID: EFGHI, from: 432, to: SYSTEM, message: 'Hello’}.
12. The server receives this message, understands it is for SYSTEM (everyone to see), and therefore adds the message 'Hello' to ALL Endpoint's messages array’s in the Endpoints data object, which are then dispatched to all endpoints (at this point the Mentor and Students are all using polling to receive messages and update their text message area when new messages come in).

Moderator Journey (made possible after the student registers as above, and wishes to use the PIN shared by the Mentor to view the Mentors stream)

1. When the student clicks the button Request Live Stream from Mentor (because they would like to become a moderator), an XMLHttpRequest is set up to send a message to the /messages route in the server, which contains the method type ‘WANT_AV’, their EP_ID, the session ID, the PIN, and ASSIGN NEW CHANNEL set to true, e.g; {MESSAGE: ‘WANT_AV’, EP_ID: 432, SID: 12345, PIN: 6789, ASSIGN NEW CHANNEL: true}
2. The PIN and SID are compared against the servers Session data object, and if they both match, a new endpoint is created with AV permissions and added to the endpoints data object only if ASSIGN NEW CHANNEL is set to true. The new endpoint row in the table would look like this; {EP_ID: 658, MESSAGES [], NAME: TIM, PERMISSIONS: ‘AV’}
3. If ASSIGN NEW CHANNEL message was set to true, the server then replies to the student (now a moderator) with a CORRECT PIN message containing the new EP_ID, e.g; {MESSAGE: ‘CORRECT PIN’, ‘EP_ID: 658’}.
4. The Moderator’s browser receives the ‘CORRECT_PIN’ message and their new EP_ID, the mentors EP_ID, and the SID, and stores all of that information in LocalStorage.
5. The Moderator's browser then opens a new window and navigates to a new URL designated to streaming (e.g. livepeers.com/stream ?)
6. The server serves responds to this request by serving some html with a video tag.
7. The Moderators browser looks up its privileged EP_ID and mentors EP_ID in LocalStorage and sends messages to the server to establish RTC
8. The server receives the message, checks to make sure the EP_ID has correct privileges, and dispatches the message to the Mentors browser.
9. A series of back and forth RTC messages are send to establish RTC from the Mentors browser to the Moderators browser

[njsfield]

Note: Need implementation to clear cookie after mentor has finished session (will discuss soon)

[njsfield]

Note: clarify the permissions model (perhaps in seperate issue)