This invention relates to media session discovery and in particular a methodand system for accessing media session descriptions transmitted over acommunications network.
Multicast transmissions are becoming increasingly common on the Internet.In contrast to standard Internet Protocol (IP) point to point transmissions (unicast), IPmulticast allows the simultaneous transmission of information to a group of recipientsfrom a single source. Routing support for IP multicast transmissions is provided by theMBone (IP Multicast Backbone) which is a virtual network layered on top of theInternet.
IP multicast allows real-time communications over wide area IP networks andtypical transmissions include video and audio conferencing, live multimedia training,university lectures, and transmission of live television and radio programmes, forexample.
A multicast transmission usually consists of a multimedia session made up ofone or more individual media streams typically carrying video, audio, whiteboard orraw data. Some sessions are persistent, but the majority exist for a specific period oftime, although need not be continuous. Multicast based transmissions on the MBonediffer from unicast IP transmissions in that any user receiving the transmission canjoin the session (unless the transmission is encrypted) and to receive a transmission,a user need only know the appropriate transmission address and timing information.
Prior to a multicast transmission an appropriate announcement containing asession description is made, usually at an IP group multi-cast address. Standardsession descriptions are generated using Session Description Protocol (SDP), asdefined in the Internet Engineering Task Force's draft RFC 2327. SDP is a simpleASCII text based protocol that is used to describe real time multimedia sessions andtheir related scheduling information. SDP messages are wrapped in a carrier protocol,known as a Session Announcement Protocol (SAP), which, in addition to containingthe necessary IP addressing and routing information for transmission across theInternet or MBone, allows the SDP message to be encrypted, signed or compressed.An announcement can then be sent at regular intervals to the announcement groupaddress. As an alternative to SAP, a session may be announced by placing an SDP message on a World Wide Web site (WWW) or by sending it to individuals by email oras a unicast transmission inviting them to participate.
An SDP message conveys information about each media stream in themulticast multimedia session to allow the recipients to participate in the session. Atypical SDP message will include the session name and purpose, the time(s) anddate(s) the session will be active, the component media streams of the session andinformation required to participate in each media stream (IP multicast address, port,media format). The SDP message may also include details of the session's bandwidthrequirements, an encryption key necessary to participate in a secure multicasttransmission using public key encryption, contact information for the organiser of themulticast session, and a Unique Resource Indicator (URI) pointing to a WWW or anIntranet web site where further information on the session may be found, forexample, background information relating to the conference.
The level of participation a user may make in a session or stream depends onits purpose. In a multicast television session, typically users would only be able toreceive the session streams whilst in a multicast conference session thecommunication would be bi-directional with a central server receiving eachparticipants transmissions and relaying them to the other participants.
A common front-end interface used by multicast end users is known asSession Directory Rendezvous (SDR). This interface takes the receivedannouncements, decodes the SDP message and displays the names of those sessionsthat are still current in a list. The end user may then select one of the listedannouncements to view further technical and user-oriented details of the announcedsession. From the displayed information, the end user can then select to joinindividual streams of the session or to join the entire session. Once the streams to bejoined are selected, SDR starts the necessary multicast-enabled multimediaapplication on the end user's computer, such as Vic, Vat, or wb etc and passes therelevant stream information (a transport port address) from the announcement ontothe application allowing the application to establish the link to the associated IPmulticast address and participate in the stream at transmission time. Having initiatedthe applications and passed the relevant transport port address SDR plays no furtherpart in the session.
Recent increased usage and demand for real time multimedia streaming on theInternet has highlighted a number of limitations with both existing session descriptionprotocols and session discovery tools such as SDR. One limitation is the lack ofinformation focus provided by the session discovery tools. For instance, SDR displaysall current media sessions irrespective of session content, timing or source address. Afurther limitation is that SDR does not provide a search function utility, that is to say,it does not allow users to search cached announcements for content specific mediasessions or multicast channels (or more precisely group addresses). This lack ofinformation focus is compounded by the fact that at the end of 1999 there were over8000 radio stations and 100 television stations "broadcasting" live on the Internet,that is to say, transmitting multicast packets comprising real time media streams tomulticast group addresses. As the demand for real time multimedia increases it isenvisaged that session discovery tools such as SDR will become overloaded andunable to present meaningful information.
World Wide Web (WWW) search engines provided by so called Web Portalcompanies or Internet Service Providers (ISP's) such as "Excite" allow users toactively search the WWW for Web pages associated with and containing informationon multicast media sessions and channels. Search engines typically comprise so-called"robots" or "crawlers" which are computer programs that continually searchthe Internet for new WWW sites and pages. These programs send back informationincluding Web page keywords and/or metadata found in Web page title blocks. Thisinformation is used to index Web pages in the search engine databases.
Information focus is also major problem with the WWW and this can affect theability of search engines to find specialised content such as Web pages containingmedia session descriptions. Moreover, the use of search engines can be problematicfor novice and unskilled users unfamiliar with concepts such as keyword searchesand search phrases.
The lack of information focus on the WWW is also a problem for multicastservice providers such as radio and television stations as it is difficult to targetsession announcements to interested parties.
According to a first aspect of the invention there is provided a method ofaccessing media session data in a database system in response to instructions from auser terminal, said method comprising the steps of:-
- establishing a communication channel between a user terminal and adatabase system, said database system comprising session specific data relating torespective media sessions available over a communications network;
- determining the identity of the user;
- retrieving user specific data for that user;
- selecting from said media sessions, in accordance with said user specificdata, at least one media session relevant to the user;
- returning session specific data identifying the relevant media session orsessions to the user terminal.
This allows a user to readily access media session data that is specificallyrelevant to that user regardless of the quantity of media session data contained in thedatabase. By retrieving user specific data the database is able to recognise mediasessions that are of particular relevance to individual users. In this way the databasecan be easily scaled to provide searching facilities for many hundreds or thousands ofmulticast channels. Thus, session announcements transmitted over the MulticastInternet or Mbone can be stored in a central database that is connected to the MBoneand accessed by remote users using dial up modems or other non-Mbone dedicatedcommunication links. Information focus is improved since users are only forwardeddata relating to media sessions that are directly relevant to them. This providesadvantages not only for database users but also for media session providers sincemedia session data is more likely to be found by interested users. The above methodovercomes many of the problems associated with searching the WWW for relevantinformation relating to media sessions. The central nature of the database providesfor economy since only the database need be connected to the Multicast Internet, theuser terminals can be readily connected to permanent or dynamically allocatedcommunication ports associated with the database in much the same way that dial upmodems connect users, or more precisely user terminals, to the Internet through aWWW Portal or ISP. When implemented in a WWW based environment thecombination of categorised session announcements and user specific data permitseach user to be presented with customised data relating to those categories ofpersonal interest, for example television media sessions categorised as sport. In thisway users can be presented with personalised "Web pages" of user selectedinformation.
Preferably, the step of selecting at least one media session comprises thestep of comparing said session specific data with said user specific data and selectingat least one relevant media session according to said comparison. This provides forefficient and accurate searching of the database for relevant session specific data.
Conveniently, said user specific data identifies at least one media sessioncategory selected by the user. In this way, session specific data can be accessedaccording to pre-defined selected categories. This improves information focus sincethe selected categories provide an information filter for user access to the sessionspecific data.
In preferred embodiments, said session specific data comprises user-orienteddata including at least one media session category. This allows media sessionproviders to readily classify the content of a media session in a sessionannouncement.
Preferably, said step of selecting at least one relevant media sessioncomprises the step of comparing said session specific and user specific category dataand selecting one or more sessions according to the comparison. This provides forefficient data retrieval.
Conveniently, a user interface environment is configured in response to useroriented session specific data being returned from the database to the terminal. Inthis way session specific data can be readily presented in a user-friendly functionalmanner to the user.
In preferred embodiments, said session specific data is transmitted to thedatabase over the communications network. This allows session providers to readilytransmit media session announcements in real time and to many databases in a singlemulticast transmission.
Preferably, the method further comprises the step of supplying dataidentifying a user request from the user terminal to the database system. In this wayusers are able to communicate with the database, for instance to change selectedcategories etc.
Conveniently, said request conforms to a structured data format. Thisprovides for improved database and communication efficiency since a request formatcan be standardised for many database users.
In preferred embodiments, the method further comprises the step of selectingin accordance with said session specific data returned to the terminal at least onemedia session to be received. In this way the user terminal can be configured toreceive a multicast transmission announced to the user by way of the transmittedsession specific data.
A media session database can be readily configured and indexed according tocategory parameters contained in media session announcements transmitted over acommunication network such as the Multicast Internet. This allows media sessionproviders such as television and radio stations to announce media sessiondescriptions over a communications network such as the Mbone so that sessiondescriptions can be cached and processed by connected databases, for instanceWWW Portal or ISP databases. By using a multicast channel to transmit sessionannouncements media session databases connected to the communications networkcan be readily updated by media session providers, that is to say, media sessiondescriptions can be "pushed" to appropriate databases over the communicationsnetwork. This has the advantage that Web Portal or ISP databases can be maintainedby caching and storing session announcements rather than by storing appropriateUniversal Resource Locators (URL's) found by Web "crawlers" or "robots". In thisway media session providers can effectively advertise media sessions to thedatabases without the databases or database users having to find the relevant Webpages beforehand. In addition, information focus and retrieval can be improved byidentifying announcements as belonging to one or more appropriate categories.
It will be understood that the order in which the steps are carried out in theabove first and second aspects of the invention does not have to be in the order setout above. For instance, the step of determining the identity of the user might becarried out some time in advance of the first step in the aforementioned first aspectof the invention.
An example of the present invention will now be described in detail withreference to the accompanying drawings, in which:
- Figure 1 is a schematic diagram illustrating a multicast transmission across theMBone;
- Figure 2 is a block diagram of a modular session description of a simplesession generated in accordance with the present invention;
- Figure 3 is a schematic diagram of a part of an MBone access network;
- Figure 4 is a schematic representation of a front end user interface for use inone arrangement of the invention;
- Figure 5 is a schematic representation of an editing window provided by theuser interface of Figure 4;
- Figure 6 is a flowchart showing a method of accessing a media sessiondatabase.
An example of an IP multicast transmission system used in one arrangement ofthe invention is described with reference to Figure 1. In Figure 1 a plurality ofuserterminals 100 are connected to the Internet multicast network (Mbone) 105 viarespectiveInternet access servers 110 which are each connected to a respectivemulticastcapable router 115. Each of the access servers is connected to a respectivelocal database system 120 which comprises asession description database 125 forstoring cached session descriptions announced on the Mbone and afurther database130 for storing user specific data relevant to end users. In the context of the presentinvention it is to be understood that the term "end user" comprises not only humanusers of theterminals 100 but also the terminals themselves and devices connectedto the terminals.
Prior to a multicast transmission, an appropriate announcement containing asession description is made to allow end users to elect to receive the transmission. Apublic multicast session announcement is made on theMbone 105 using a single wellknown group IP multicast address dedicated to the transmission of sessionannouncements. Each access server that has elected to join the IP multicast groupaddress receives the multicast session announcement. The concept of joining an IPgroup address is analogous to that of a television or radio receiver being tuned to aparticular frequency or "channel" to receive a television or radio broadcast on thatchannel.
In one arrangement, each user terminal that elects or is elected to receive thetransmission is linked to the IP multicast group address identified in theannouncement and the routers associated with the elected terminals are configured toreceive multicast packets addressed to that group address. The session streams arethen transmitted from one ormore media sources 135 to the terminals of themulticast group.
In another arrangement, user terminals connect to the media source IP addressidentified in the session announcement and separate unicast media streams aretransmitted to the IP addresses of the respective terminals. Thus, there is norequirement for the terminals to be multicast enabled.
Figure 2 is a block diagram of asession description 200 for a simple televisionsession. The session description does not conform to SDP although SDP could beused in an alternative embodiment to that described. Thesession description 200comprises abase module 210 linked to amedia module 220.
Thebase module 210 contains user-oriented session specific data includingthe session title and timing information. In particular the base module includes acategory field for session classification purposes. In the example shown below thecategory field of the media session is "Entertainment". Other categories for televisionsessions include for example, news, sport, movies, documentary, science, drama etc.Appropriate categories for other real time media sessions are also envisaged. Thesesessions include radio sessions, live or archived music sessions and networked gamesessions, for example. A category field may be added as a so called "attribute"extension field to session announcements constructed in accordance with SDP.
Thebase module 210 may also include a description or abstract, contactinformation about the organiser and a WWW or an intranet URL pointing to a web sitecontaining further information. Thebase module 210 contains information necessaryfor the user to decide if they are interested in participating in the session. Themediamodule 220 contains announcement data relating to a video stream of the session.Themedia module 220 contains the technical information necessary for the userterminal to receive the associated media stream. In particular, connection, timing andmedia format details are provided. The connection field of the media module containsthe group IP multicast address and port number from which the media stream can bereceived, or alternatively, the IP address of the media source if the media stream isunicast.
An example of a
session description 200 generated for a television mediasession is shown below:
Thebase module 210 has a unique identifier (id field) used in the generation oflinks between two modules during the processing of the session description. Themodule field of thebase module 210 lists the type and unique identifier of themediamodule 220 linked to thebase module 210. The second identifier in the id field of themedia module 220 is the unique identifier belonging to thebase module 210 linkingthe media module back to thebase module 210. By extension, these two-way linkspermit a module tree to be traversed from a base module downwards or from a mediamodule upwards.
In the system architecture of Figure 1, theInternet access servers 110 areeach configured to listen to the dedicated group address and cache sessionannouncements announced to that address. In an alternative arrangement a dedicatedproxy server could be used for this purpose, to free local system resources forinstance. In this way remote procedural calls could be used to periodically downloadthe cached announcements from the proxy server to one ormore access servers 110.
Referring now to Figure 3, eachserver 110 comprises acache 300 for cachingsession announcements transmitted to the dedicated group address, aSAP parser305 for parsing cached session announcements and asession description parser 310for parsing session descriptions contained within the session announcements. Thesession description parser 310 is configured to identify appropriate parameters in thesession description 200 for database classification and indexing purposes. Once parsed the session descriptions are stored in thesession description database 125.Theserver 110 is further provided with afirst database interface 315 for accessingthe session description database and asecond database interface 320 for accessinguser specific data in thedatabase 130.
In one arrangement the data contained in the sessionspecific database 125comprises data entries for at least all the fields shown in the examplemodular sessiondescription 200 previously described. For instance, thedatabase 125 comprises anentry for the id field, information field, source field, category field etc, of the basemodule and an entry for the id field, media field, and connection field of the mediamodule. Thedatabase 125 is configured to recognize each media sessionannouncements as belonging to a particular media session category as defined in thecategory field of respective session announcement. In this respect a plurality ofcategory names are defined so that each media session announcement contains anentry in its respective category field that is identifiable by thedatabase 125 accordingto a standard list of category entries stored in thedatabase 125.
When a session announcement containing a session description is receivedover the communications network it is first cached by thecache 300. TheCache 300stores the session announcement in its pre-processed form, that is to say as aplurality of cached SAP IP packets. The announcement is then processed first by theSAP parser 305 to determine the session description contained in the sessionannouncement and then by thesession description parser 310 to determine thecontents of the session description, that is to say to identify the data entries in eachof the respective fields of the session description. In particular thesession descriptionparser 310 identifies which respective category the session description belongs toaccording the respective category field data entry that is contained in the sessiondescription. The parsed session description data is then stored in thedatabase 125where it is classified according to its respective category field for subsequentretrieval.
Database 130 stores user specific or user profile data relating to the real timemedia preferences of each respective user registered with the database. Thesepreferences comprise timing preferences, content or category preferences, mediachannel or session provider preferences, for example. In this respect a user profilemay include a pre-determined preference for each data field contained in the session description.
Theaccess server 110 also includes afirst communications interface 320 forcommunicating with the user terminals connecting or connected to it. In thearrangement shown thecommunications interface 325 provides an IP connection tothe user terminals for the transfer of HTML or XML request and response messagesusing the hypertext transfer protocol (HTTP). Asecond communication interface 330is provided for receiving multicast IP packets from the associatedrouter 115.
An example of a front-endgraphical user interface 400 for theuser terminals100 is shown in Figure 4. The user interface allows users to interact with the localInternet access servers 110 for receiving real time multicast media streams andaccessing thedatabase 130. The user interface is divided into five main area blocks.
Thefirst block 405, to the right of the drawing in Figure 4, comprises a mainmenu including four buttons which relate to four different streamed media channeltypes. Afirst button 410 is labeled "TV" and is used to access media session listingsfor one or more television channels, asecond button 415 is labeled "Radio" and isused to access session listings for one or more radio channels, athird button 420 islabeled "Music" and is used to access media session listings for live and archivedmusic channels and afourth button 425 is labeled "Games" which is used to accesslive networked game media session listings. A user selects one of the four mediachannel types to be displayed by positioning a mouse cursor over the appropriatebutton and executing a mouse click or other suitable command.0
In the drawing of Figure 4 theTV button 410 has been selected and thelistings for various television channels are displayed in asecond block 430 whichcomprises the central lower portion of the interface shown in Figure 4. In the drawingpartial listings for three television channels "BBC News 24", "BBC One" and "BBCTwo" are shown side by side in respectiveadjacent sub-blocks 435, 440 and 445within thelisting block 430. These three channels are displayed in the foreground inblock 430. The listings for two other channels "Channel 4" and "Channel 5" areshown in the background and may be moved to the foreground for display by userselection of an appropriately labeledtab 475 by mouse click or otherwise. The listingsare displayed in chronological order andscroll bars 450 are provided on the right handside of the sub-blocks to enable users to scroll the display up and down using mouseor keyboard commands to navigate channel listings for an entire day. As shown, the sub blocks 435, 440 and 440 comprises afirst column 455 that indicates the time oftransmission of the media session and asecond column 460 that indicates the title ofthe media session.
A third block 465 is positioned above thelisting block 430 in the drawing andcomprises sevenbuttons 470, one for each day of the week. Selection of one ofthese buttons by mouse click or other like command displays the corresponding day'slistings for the current foreground channels in thelisting block 430.
An important feature of theuser interface 400 is that it allows users to displaylistings for all channels of a specific type, for example television or radio, or only apre-determined set of user selected channels. Similarly, the user interface allowsusers to display listings for all categories of media session, such as news orentertainment, or only a pre-determined set of user selected categories.
Afourth block 480 is positioned towards the top of the drawing andcomprises threebuttons 482, 484 and 486. Thefirst button 482 is labeled "Allchannels" and its selection by mouse click or like command causes the listings of allchannels from a list of channels to be displayed. In the interface shown in Figure 4only the first three channels are actually displayed in the foreground, the remainderare accessible from the background by clicking on background tabs liketab 475 aspreviously described. Thesecond button 484 is labeled "Your channels" and itsselection causes the listing of only a pre-determined set of user selected channels tobe displayed. Thethird button 486 is labeled "Change your channels" and itsselection allows a user to change their selected channels. The function ofbutton 486will be described in greater in the description relating to Figure 5 later in thespecification.
Thefifth block 490 is positioned to the left of the drawing and comprisesthreebuttons 492, 494 and 496. Thefirst button 492 is labeled "All categories" andits selection by mouse click or like command causes the listings of all categories ofmedia session from a list of categories to be displayed. Thesecond button 494 islabeled "Your categories" and its selection causes the listing of only a pre-determinedset of user selected media session categories to be displayed. Thethird button 496 islabeled "Change your categories" and its selection allows a user to change theirselected categories. The function ofbutton 496 like 486 will be described in greaterdetail in the description relating to Figure 5 which follows.
Referring to Figure 5, when a user selects the option "Change your categories"by clicking on button 496 awindow 500 is displayed on the user terminal. Thewindow 500 comprises twocategory boxes 505 and 510 which are position side byside in spaced relation. Both boxes contain a list of categories which together definea complete list of categories for the available media sessions. The boxes are bothprovided withscroll bars 515 which allow up and down scrolling of the text in therespective boxes by the user.Box 505 which is on the left of the drawing containsthe media session categories that are not of interest to the user andbox 510 which ison the right contains those categories that are of interest to the user. Twobuttons520 and 525 are provided for moving categories between the two boxes. The firstbutton 520 allows a user to add a selected category frombox 505 tobox 510 andthesecond button 525 allows a selected category to be removed frombox 510 tobox 505. Categories are moved between boxes by the user selecting the categorythat is to be moved, by mouse click or otherwise, and then selecting the appropriatebutton. When all the changes have been made they are saved by theuser selectingbutton 530 by mouse click or other like command.
When a user selects the option "Change your channels" by clicking on button486 a similar window (not shown) towindow 500 is displayed on the user terminal.The window is the same aswindow 500 except that it lists channels instead ofcategories and allows changes to be made to "Your channels" instead of "Yourcategories". These category and media channel preferences are stored as part of auser profile for each user in thedatabase 130. These records are updated each time auser changes their respective preferences at a user terminal.
Referring now to the flowchart of Figure 6. A user wishing to access mediasession announcements held in thedatabase 125 is required to input an allocatedunique personal identification code and password at a user terminal instep 600. Instep 605 a communications link is established between the user terminal and arespective Internet access server. The user identification code and password areverified by the access server instep 610 and if verification is confirmed the userterminal is granted access to thedatabase system 120 under control of the server instep 615. The user is then prompted to send a request to the server from the terminalinstep 620 to display cached session announcements according to the user's pre-definedselections for one of the four media stream channel types. If a request is sent the server accesses thedatabase 130 and retrieves the user profile or user specificdata for the identified user instep 625. The access server then accesses thesessionannouncement database 125 instep 630 and retrieves the session specific data foreach session that matches the user profile for the requested channel type. The data isthen sent as a response to the user terminal for manipulation and display by the userinterface.
The user may request more information about a particular session by clickingon the title of the session in thelisting block 430. This command is recognised by theuser terminal and a further request is sent to the access server for further informationcontained in the relevant session description, for instance an abstract or press review.If further information is available this is sent to the user terminal for display by theuser interface. If the media session is being transmitted or is about to be transmittedthe user can elect to join the session to receive the media stream by clicking a joinnow button (not shown) presented on the user interface. If the user elects to join asession a network HTTP connection is made to the media steam server identified inthe connection field of the respective session description. The connection provides alink between the user terminal and the media stream server for the transfer of HTMLor XML structured data requests. Media stream data is transferred to the userterminal using Real Time Protocol (RTP) over UDP, for instance.
The user may send a request to view the cached session descriptions of adifferent media channel type, for instance radio instead or television, by clicking theappropriate button in the main menu block. HTML or XML requests are sent to theaccess server by the user terminal to view the relevant session descriptions.
Although the present invention has been described with specific reference tothe Internet and multicast it will be apparent that the described methods areapplicable to other communication transport mechanisms, in particularcommunications networks that are configured to transport multicast packets overnon-multicast uni-cast tunnels.