 If you visit YouTube and try watching a video, it's usually a single user operating the controls on YouTube video player. So you click the play button and the video starts playing. That is something which is very simple and we've been through certain content that talks about how such streaming is brought about. In content delivery networks, collaboration is something that is always encouraged and there are a myriad of services and applications where collaboration is required. In this module, we'll talk about media playback or media streaming on CDNs. Now how the CDNs are going to offer because CDNs are supposed to provide the underlying infrastructure regardless of the applications which are using those. But here we shall see that an awareness or cognizance is required for achieving collaborative media streaming. So we'll talk about all these issues in this module. We know that CDNs do provide a very efficient solution to provide media streaming. TV broadcast, video on demand like watching a movie over Netflix or Amazon Prime is something that we are all familiar with. However, the modern multimedia applications even go a stage further and the applications themselves sometimes create the content, modify and manage it at their own. So this means that amongst multiple entities, the content is being created in a distributed manner. And then this content is placed at appropriate locations. This now means that some kind of collaborative playback is required where the content is being played or streamed by multiple users who need to have some kind of unison or coordination. Formerly, what is a collaborative playback? It is actually an enablement infrastructure that is created or realized to explicitly form a synchronous group of users who all can select, watch and cooperatively control a remote media playback file. This sounds interesting, but immediately certain challenges would come into mind. Let's get into some more detail. So the collaborative playback session of some multimedia streaming content is going to be synchronously transmitted to all the members. It means theoretically speaking, they all would be on the same frame because the delivery is going to be different, but the play out has to be such that they all are on the same frame at one point in time. But if a user has to initiate some kind of active session control, for instance in video cassette recorders, we had typical buttons like play, rewind, forward known as seek, pausing or even stopping the multimedia content, say a video. Any member can initiate that. Now this actually could involve some kind of conflicting situations. In order to resolve the playback sessions must provide some kind of interaction between the members. Now this playback session to be done collaboratively requires some core services. The first service is group formation and management service. Here there would be a leader or an organizer that invites individual users to join the group through invite based subscription. Then the media streaming is a service which would be required because the actual delivery of the object has to be executed. Then we need to have some kind of user control that is commands to allow the members to control the execution of the transmission of the stream. And then some kind of interaction between the users is required, say a basic text based messenger through which they all develop knowledge and reach at a consensus on whom to give the control of the video stream. In CDNs the reference architecture could be thought of as a streaming and control server at the top which uses communication services and it's going to be unicast, it could be multicast or it could be broadcast. Since we are talking about collaboration it has to be at least multicast. Amongst certain users each user has a client entity known as the collaborative client. Here you can see on the visual at the left hand side that the control messages are being sent from the collaborative clients and the media is being delivered to the client in a synchronous manner. Now these clients would be playing the video by using certain controls so the automaton of the collaborative media service, play out service can be thought of as simply the execution of the play functionality and then pausing it and eventually stopping it. So it is as simple as a basic automaton. While this seems very simple we can think about use cases where smooth collaboration takes place between the collaborating clients. But sometimes there could be conflict. Here three different scenarios or sequence diagrams are presented. The first one is where it is only one client that initiates a request to modify the play out pausing, winding, forwarding etc. Then the central server updates the content accordingly and streams it towards the clients. In scenario B we see that there is a command from client one which is delivered at the communication server without a problem. But as far as the client two is concerned the command that it sends is either corrupted or not delivered or probably there is some delay. Because of that the command one is executed and correspondingly the play out is altered. In the third situation actually some kind of contention is going to happen because the two commands from two different clients reach at the server exactly at the same time. So some kind of conflict resolution strategy for instance identifier who has got the higher identifier or what is the precedent in terms of queuing or for that matter some privilege or organizer level administrative users could be given preference. So using these three possible scenarios or their variants could also be thought of a collaborative media streaming service could be realized and interesting play out can be visualized across the content delivery network. The reference again is by Raj Kumar Bhaiya content delivery networks.