Technical field

The technology disclosed herein relates generally to the field of cloud based communication systems, and in particular to architectures for and configuring of communication paths within such cloud based communication systems.

Background

A traditional model for delivering real-time communication servicesto e.g.

enterprises has been to install dedicated communication hardware and software within the enterprise premises. In this model, the enterprise purchases the communication infrastructure and deploys it within itsown premises. The enterprise also takes care of the maintenance of its on -premises communication infrastructure.

Today, an increasing number of cloud-based providers offer their servicesto enterprise customers. The cloud providers are offering their equipment, in particular virtualized communication serversin their data centers, and also take care of maintaining the servers and cloud network on behalf of the enterprise customers.

There is a need for cloud-based hosted communication services si nee far from all enterprises can afford or want to invest time and resources in building their own on- premises communication solution. Instead, these enterprises want to outsource the complexity of maintaining the infrastructure required by the communication solution to athird party provider, that is, to the cloud service provider. A challenge that the cloud service provider faces is the running of a complex communication service and its components in itsown cloud network for multiple enterprise customers in parallel. The architectures of present-day real-time communication systems are highly complex. Typically, these solutions use a layered architecturedividing nodesinvolved in the communication system into media plane nodes and control planenodes. The number of control plane nodes in particular can be very high. As an example, in the Third Generation Partnership Project (3GPP) IP (Internet Protocol) Multimedia Subsystem (IMS) architecture, there are several control planenodes, including among others Call Session Control Functions (CSCF): Proxy CSCF (P-CSCF), Interrogating CSCF (l-CSCF), and Serving CSCF (S-CSCF); edia Resource Function Con t r ol I ers( RFCs), SIP (Session Initiation Protocol) Application Servers (ASs), and Session Border Controllers (SBCs). The I MS architecture is perhaps the most extreme example, but in general, architectures of standardized communication systems are fairly complex.

For acloud service provider that needs to host thefull set of nodesrequired todeliver communication servicesin itscloud infrastructure for multiple enterprise customers in parallel, the situation is highly challenging. The resulting complexity, i.e. the need to run multiple virtualized control and media plane nodes in thedatacentersand to manage the interconnections between these components, makes it more expensive to providethe communication service and also makes maintenance of the

communication system more difficult. Thus, it is clear that cloud service providers would benefit from more simple and thus more cloud-friendly real-time

communication system architectures. In addition to cloud service providers, also enterprises running virtualized

communication solutions in their private clouds could benefit from simpler com m u n i cat i on servi ce arch i t ect u res.

Summary

An object of the present disclosure is to solve or at least alleviate one of the above mentioned problems.

Theobject is according to a first aspect achieved byamethod performed in anodefor configuring a communication path for a media service. The communication path is configured in acloud network comprising at least one media processing unit configured to handle media processing required by the media service, and the node is located along the communication path. The method comprises: discovering at least one media processing unit by obtaining location information for the at least one media processing unit; and configuring the communication path between end user communication devices of the media service by interconnecting one or more of the discovered media processing units. The method provides a self-organizing media plane architecture wherein centralized controller nodes, e.g. control plane modules such as the M RFC and AS virtual machines, are removed and asimp!ified architecture for cloud-based real-time communication services is enabled. Instead of various centralized controller nodes setting up a communication path between end users by using control signaling, a node that is located along the communication path itself discovers one or more media processing unitsand configuresthecommunication path. Thenodemay beamedia processing unit processing media streams for the media service or an end user communication device.

The object is according to a second aspect achieved by a node for configuring a communication path for a media service. The communication path is configured in a cloud network comprising at least one media processing unit configured to handle media processing required by themediaservice. The node is located along the communication path. The node comprises a processor and memory, the memory containing instructions executable by the processor, whereby the node is operati e to: discover at least one media processing unit by obtaining location information for the at least one media processing unit; and configure the communication path between end user communication devicesof themediaservice by interconnecting oneor more of the discovered media processing units.

The object is according to athird aspect achieved by a computer program for anode for configuring a communication path for a media service. The communication path isconfigured in acloud network comprising at least one media processing unit configured to handle media processing required by the media service. Thenodeis being located along the communication path. The computer program comprises computer program code, which, when run on the node causes the node to: discover at least one media processing unit by obtaining location information for the at least one media processing unit; and configure the communication path between end user communication devicesof the media service by interconnecting oneor more of the discovered media processing units.

The object is according to a fourth aspect achieved by a computer program product comprising a computer program as above, and acorn puter readable means on which the computer program is stored.

The object is according to a fifth aspect achieved by a node comprising meansfor discovering at least one media processing unit by obtaining location information for the at least one media processing unit, and meansfor configuring the communication path between end user communication devices of the media service by

interconnecting one or more of the discovered media processing units.

Further features and advantages of the present disclosure will become clear upon reading thefollowing description and the accompanying drawings.

Brief description of the drawings

Figure 1 il!ustratesaprior art real-time cloud network.

Figure2 illustrates schematically an environment in which embodimentsof the present disclosure may be implemented. Figures illustrates a point-to-point topology in accordance with an aspect of the present disclosu e.

Figure 4 illustrates a cloud infrastructure using database media servers in accordance with an aspect of the present disclosure.

Figures illustrates a cloud infrastructure using multicast in accordance with an aspect of the present disclosure.

Figures illustrates a point-to-point cloud topology in accordance with an aspect of the present disclosure.

Figure7isaflow chart illustrating operations performed in anodein accordance with the present disclosure. Figure8 illustrates aflow chart over steps of a method in anodein accordance with the present disclosure.

Figure9 illustrates schematically a node and meansfor implementing methods of the present disclosure.

Figure 10 illustrates a node comprising function modules/' ^" software modules for implementing methods of the present disclosure.

Detailed description In thefollowing description, for purposes of explanation and not limitation, specific details are set forth such as particular architectures, interfaces, techniques, etc. in order to provide a thorough understanding. In other instances, detailed descriptions of well-known devices, circuits, and methods are omitted so asnot to obscurethe description with unnecessary detail. Same reference numerals refer to same or similar elements throughout the description.

As described in the background section, a cloud-based real-time communication system needs some specific control and media plane nodes to perform media related control and manipulation functions. In the I MS architecture, the latter, i.e. media manipulation functions, are provided by a system called the Media Resource

Function (MRF). In thefollowing, a media related module is referred to as a Media Resource Function (MRF).

Basically, each MRFisdivided into a Media Resource Function Controller (MRFC) and a Media Resource Function Processor ( RFP). The MRFC is a control plane node that interprets information coming from an Application Server (AS), the information being used for controlling the MRFP. The MRFP is a media plane node used for mediafunctions, such as for example video and audio transcoding, video and audio mixing and switching, and medi transport adaptation.

Figure 1 illustrates a prior art solution on how the MRF (comprising M RFC and MRFP) and the signaling channels and media channels may be defined in acloud- based real-time communication system. In thefigure 1, clientsA, B and Care contacting a M RFC, which is running on a virtual machine within avirtualized server in adata center, before joining a media session. ClientsA and B are contacting a first RFC in a first data center 1 and the client C is contacting a second RFC in a second data center 2. This is illustrated in thefigure 1 by lines indicated by S (for signaling channel). The MRFC instructs the MRFP (also running on avirtual machine and denoted MediaServer in thefigure 1) to createanew session between the three clients. This instructing is illustrated in thefigure 1 by lines indicated by C (control channel), and the created communication paths between the MRFPsfor the session is illustrated by lines indicated by M (media channel). It is noted that Figure 1 is highly simplified, and that a real-life cloud-based communication system might need to use a very high number of virtual machines for M RFC, RFP, AS, and further control plane nodes to serve participants of for instance a massive scale geographically distributed multimedia conference session.

Briefly, the present disclosure provides a self-organizing media plane architecture wherein control plane modules such as the M RFC and AS virtual machines are unnecessary and may beomitted. This greatly simplifiesthearchitectureof cloud- based real-time communication services. The disclosure also provides different meansto control the MRFPs (i.e. virtualized mediaservers) without using any MRFC (i.e. control plane) modules.

Thus, the present disclosure provides a simplified architecture of cloud-based real- time communication systems by removing the control plane modules such asMRFCs from the architecture. In the absence of MRFC nodes, a cloud-based communication system hasto have other meansto control and utilizethe mediaserver virtual machinesii.e. MRFPs) of the communication system. Various ways of accomplishing thiswill be described next. In particular, four different methods to discover MRFPs (also denoted mediaservers) in thecloud network without using any MRFCnodes (also denoted media controllers) will be described. A first way is to store the M RFP (i.e. mediaserver virtual machine) locations and capabilities in a (possibly decentralized) database system. A second way isto use multicast -based M RFPdiscovery. A third way isto use point-to-point cloud communication. A fourth way isto use a combination of the previous ways. In the following, each of these ways to discover MRFPs without an MRFC will be described more in detail.

A note on vocabulary may be in order: a M RFP virtual machine instance is also denoted simply MRFPor amediaserver or mediaserver instance, and each media server instance is running in one Virtual Machine(VM) within adafacenter.

A first embodiment for discovering media servers comprise storing information about M RFPs i n a database system . The database system may be a si ngle database or a distributed database system. A new component is provided in thecloud network which isdenoted Database Media Server (DMS) in the following. A Database Media Server may be implemented asaserver instance running in avirtual machine within adatacenter. The DMSmay also comprise distributed server instances running in virtual machinesin different datacentersor in a single datacenter. The DMSstores information relating to an address, e.g. IP address or domain name system (DNS) name, of every RFP virtual machine instance in the cloud network. TheDMSmay also store some extended information about every MRFP. In other words, the DMS acts as a tracker, keeping track of RFPs, their addresses and capabilities. Users wishing to establish or join amediasession can query the D Sin order to obtain information about (i.e. address of) RFPs in the cloud network. In addition to the address of every RFP, the information maintained by the D S may contain details such asfor example the degree of security of thedatacenter (e.g. aserver) in which it exists, the geographical location of thedatacenter (expressed for instance as geographical coordinates), the number and types of codecs supported by the MRFP, the types of media processing operations the MRFP supports, and/ or the maximum capacity and current load of the M RFPs.

A DMS may have sensitive information about the topology of the cloud network, and therefore, in an embodiment, the users of the cloud network are requested to perform some authentication mechanism to restrict unauthorized users' accessto that information. Depending on the level of authorization of a user, the DMSwill provide the user with thefull topology information of the cloud network, partial information, or no information at all. As an example, in certain scenarios the operator of the distributed cloud network where the M RFPs are running may not be willing to expose the information about all M RFPs to the users. To prevent this, the operator may introduce filtering logicin theDMS. ThislogicallowstheDMSto return information only about a subset of the M RFPs to the user. As an example, the DMS may return information only about M RFPs that are located geographicall close to the user. This may be implemented by determining the rough geographical location of the user based on the source IP address of thequery or information provided by theuser in thequery. As another example, the DMS may return only one MRFP in every datacenter (instead of returning thefull list of M RFPs). Finally, if the user has specified requirements for the MRFPs, e.g. requi ements on supported codecs, required media processing operations, latency, bandwidth, location, CPU power, etc., in her query sent to the DMS, the DMS may only return information about those RFPsthat fulfill the requi ements. The authentication process and the maintenance of the information in the DMSmay be implemented using Lightweight Directory Access Protocol (LDAP). LDAP provides a secure way of accessing and maintaining the information in the DMS.

When an RFP joins or leaves a network, the RFP should inform the DMS.

Thereby, the DMSmay update the topology information it maintains about the cloud network accordingly.

Figure 2 illustrates an exemplary cloud communication system 10 using Database edia Servers. As illustrated in thefigure2, clientsA, B and C (indicated in figure2 also by reference numerals 15, 16 and 17, respectively) may obtain information about the available MRFPs in the cloud network 20, 21 (illustrated as two separate clouds) through theDMS12, 13, located in a respect! ved at acenter (denoted DCin thefigure 2). As was described earlier, the DMS 12, 13 comprises a list of the locations of the MRFPs 14i, 142, 14 ₃ , 14 ₄ within the cloud network 20, 21. The DMS 12, 13 may also maintain ametadatafilewith extended information about every MRFP 14i, 142, 143, 14 ₄ . Such extended information may comprise varioustypes of metadata, defining e.g. encoders or format to storevideo and audio. An example of such metadata file (in XLM) is:

<?xml version="1.0"?>

<mediaMediaServers>

<mediaServerl>

<name>Server 1 </name>

<ip> 123.123.123.123 </i p>

<codecs>

<control>VP8 </control>

<control>MP4</control>

</codecs>

</mediaServerl >

<mediaServer2>

<name>Server 2 </name>

<ip> 123.123.123.124</ip>

<codecs>

<control>VP8<control> </codecs>

</mediaServer2>

</mediaServers>

It is noted that although figure2 ί Hustrates the DMSs as centralized virtual serversin the cloud network 20, 21 (in a respective datacenter in the respective cloud), the DMS may also be implemented as a distributed database among the MRFPs 14i, 142, 14a, 14 ₄ (in the respective cloud network 20, 21). Such distributed DMS may be

implemented for instance using a Distributed Hash Table (DHT) based overlay network. The DHT overlay network can be maintained for instance using the

REsource Location And Discovery (RELOAD) Peer-to-Peer (P2P) signaling protocol. When adistributed DMS is used, users may accessthedistributed database using the secure RELOAD protocol. A benefit of using adistributed database is that the provider of thecloud communication service does not need to maintain centralized database servers, alleviating the need to purchase and maintain such centralized database servers thus lowering costs. In such distributed database, theinformation would then be distributed among different mediaservers.

A second embodiment for discovering media servers comprises ulticast -based M RFP Discovery. In particular, architecture is provided wherein the MRFPs exchange information about their locations through multicast channels. The users of the cloud-based communication system 10 may subscribe to this channel in order to receive the packets that MRFPs send to that group of subscribers. Also the MRFPs themselves may be seen as members of the group.

The multicast channel may be configured to only transmit the information to the users who subscribe to the multicast group. In addition, since native network-level multicast (also denoted IP multicast) is used, theinformation may be sent using the most efficient strategy and messages are delivered over each link of the network only once. In particular, native multicast implements multicast service at the IP routing level, with each individual packet transmitted from the source, duplicated at routers, and then delivered to multiple receivers simultaneously. It is noted that the particular strategy may be specific for each cloud provider to minimize the amount of resources used in thecloud communication system by the multicast channels. In other words, every provider may have itsown resource allocation schemes depending the number of services and resources in thecloud communication system. By using multicast, in contrast to broadcast (wherein all users receive messages), it isensured that the cloud network 20, 21 isnot flooded with messages carrying mediaserver information.

Once a user joins the multicast group, her device will start receiving information in a multicasting fashion about thedifferent RFPsin the cloud network 20, 21. Every RFPwill send apacket to the channel informing about itsexistence. Such packet sending may be performed periodically. Every MRFPwill thus send its information in a certain amount of time, for instance, every 5 minutes. Such implementation avoids collapsing the cloud network with to man messages at the same time.

After that, the user can contact the M RFPs whose capabilities and/ or locations meet the requirements of the user in order to join or establish a multimedia session. The user may contact the selected M RFPs directly to obtain more information about them.

It is noted that the mechanism described above requires native I P- level multicast support from the cloud network. That is, in order for the user to be able to receive information delivered in amulticast fashion, the cloud network needs to support native multicast. However, many cloud networks today do not yet have such support. In the absence of native IP-level multicast, an Application- Level Multicast (ALM) overlay network may be constructed among the M RFPs and the end users of the cloud communication system 10. The ALM overlay network can then be used in a manner similar to a native IP-level multicast network.

It isfurther noted that if the user's communication device remains a part of the multicast group for a longer period of time, the communication device may receive potentially a high amount of messages if the distributed cloud communication system 10 containsahigh number of MRFPs. In particular, each MRFP sends a packet about itself and messages are transmitted as M RFPs are added. The high amount of incoming traffic may also drain the battery of the device if the device is battery- powered. However, in practice this is in most cases not a problem si nee the user is typically apart of the multicast group only for a short period of time; the user can chooseto leave the multicast group as soon as she has obtained enough information from it.

Sincethe multicast-based discovery mechanism revealsahigh amount of information about the cloud network 20, 21 to the user, it is very suitable for trusted environments such as enterprise networks. Further, it is noted that this mechanism may not be appropriate for very large cloud networks si nee this would imply a high frequency of MRFP information being sent to the multicast group.

A third embodiment for discovering media servers comprise a point-to-point cloud configuration. In particular, this is a simple configuration where every user has a permanent link to one so-called First-Hop RFP (FH- RFP) that the user has discovered for instance using the Domain Name System (DNS), dynamic DNS, or any other mechanism, such as through using alocal broadcast in its local subnet. Figures illustrates such cloud topology. For example, client A (also denoted by reference numeral 15) has as its FH-M RFP, the MRFP denoted MS-A in figures, client B (also denoted by reference numeral 16) and client C (also denoted by reference numeral 17) both haveastheir FH-MRFP, the MRFP denoted MS-BCin thefigure. Client D (also denoted by reference numeral 18) and client E (also denoted by reference numeral 19) have correspondingly their FH-MRFPs. In thefigureS, the lines, indicated by letter M, from clients to M RFPs indicate media channels. All the mediatraffic originating from and destined to the user will go through this FH-M RFP. The end-to- end media paths between the users and the M RFPs (that is, the interconnections between users, FH-MRFPs, and other M RFPs in thecloud) can be defined either by the different M RFPs or by the users. In the latter alternative, the user can inform its FH-M RFP about the interconnections needed for her service.

In addition, the FH-M RFP can inform the user about the existence of other RFPs, that is, it can inform about the interconnections that are possible to establish in the cloud network 20, 21.

In this model, every user will be linked to one FH- RFP. In contrast, a single FH- MRFP can be linked to many users at the same time. This is illustrated in thefigureS in that clients B and Care connected to the same FH- RFP. However, for the sake of redundancy or load balancing, a user may also connect to multiple FH-M RFPs in parallel - if the primary FH- RFP becomes overloaded or crashes, the user can direct her traffic to one of the secondary FH- RFPs. A fourth set of embodiments for discovering media servers comprise any combination of the above described three embodiments. For instance, every user may be linked to one FH-MRFP (First-Hop MRFP) and this MRFP can learn about the topology of the cloud network 20, 21 by obtaining the information from a Database Media Server (DMS).

As another, every user may be linked to one FH-MRFP( First-Hop RFP) and this FH- RFPcan learn about the topology of the cloud network 20, 21 by obtaining the information from a Multicast Channel.

Once the locations and capabilities of the MRFPs in the cloud network 20, 21 are known to the user through the use of one of the mechanisms for discovering the MRFPs, as has been described, the cloud network 20, 21 should provide means to configure some (or possibly all) of the discovered M RFPs into a deli very hierarchy necessary to support a media session. That is, the MRFPs need to be inter-connected to each other.

The process of organizing the MRFP vi tual machines into a media delivery hierarchy, that is, the process of interconnecting the RFPs, may be implemented in different ways. Although some particular embodiments will be described next, the cloud communication system 10 may also use other type of methods to choose which MRFPsto interconnect into a media session. Thus, any of thefollowing

interconnection mechanisms may be used:

User-driven interconnection process: the creator of aservice, e.g. a conference or media session, which for instance may be the user who started the service, or the administrator of theservice, can assign the specific MRFPs to be used in theservice.

User voting based interconnection process: every user in the service, e.g. conference or media session, can vote for her candidate MRFPs and, democratically, the MRFPs with the most votes will be selected for theservice. · 3rd-party driven interconnection process: a third party component may automatically, for instance, based on the capabilities and locations of the MRFPs, assign theMRFPsto be used in aparticular service, e.g. mediasession. In some special scenarios, the third-party can beauser not participating in theservice, e.g. not participating in a conference. · Self-organizing interconnection process: the cloud communication system can be completely self-organizing. That is, thefirst user in theservice, e.g. media session, uses one of the mechanisms described earlier (i.e. DMS, multicast, point-to-point discovery, or combinations thereof) to find an initial RFPto which he connects. After this, the initial RFP applies one of the mechanisms recursively to find the next RFP (or destination user in case of for instance a two-party call) to which to connect. This process continues whenever new user joins the media sessi on .

Next, different use cases will be described for a user who wants to create a

multimedia session, e.g. a conference service, with another user.

In the use case described in various examples below, user Aand user Bcreatea conference service between them using a (Distributed) Database Media Server.

In afirst example of this use case, a user-driven interconnection process using DMS- based discovery is described with reference to figure 4. In this use case, it is assumed that user A will be the administrator of the conference. The user-driven

interconnection process begins when users A and B decide to establish the

conference.

As an administrator, user A will first have to contact the Database Medi Server (DMS) 13 (in datacenter denoted DC2) to obtain the available MRFPs 14i, 14 ₂ , 14 ₃ , 14 ₄ in the cloud network 20, 21. The user A may obtain the address of the DMSthrough a variety of different means, e.g. through DNS, atrusted website, local broadcast in its subnet (when appropriate), or configuration. In thecaseof adistributed DMS 12, 13, the user A may learn the address of an existing peer (i.e. existing DMS) in the DMS overlay from a RELOAD enrollment server. A database interface is illustrated in the figure as lines denoted by letter "D" from the client A (of user A), totheDMS13 (in datacenter DC2) to the DMS 12 (in datacenter DC1). The user A may access the DMS 13 using some existing protocol for accessing distributed information services over IP networks. LDAPand XML enabled directory (XED) are examples of such protocols but the present disclosure is not limited to these protocols, others could alternatively be used. In thecaseof adistributed DMS 12, 13, the RELOAD protocol may be used. The user A may filter his queries to obtain the most appropriate M RFPs 142, 14 ₄ . For instance, he may filter thequeriesto obtain the M RFPs having the lowest load in the cloud network.

Once the user A has obtained the avai lable M RFPs, he, as the conference

administrator, may choose the M RFPs which are to be used for the media plane and may contact those M RFPs in order to create the interconnections between them. As user A has the IP addresses of the different RFPs, each MRFPmay be contacted directly; the user contacting the M RFP by sending a signaling protocol (e.g. session initiation protocol, SI P, Hypertext Transfer Protocol, HTTP, Extensible Messaging and Presence Protocol, XMPP etc.) messagetoit. In the case illustrated in figure4, the user A chooses M RFPs 142, 14 ₄ and a media channel is set up between user A (having client A) and user B (having client B), the mediachannel indicated by lines denoted by letter "M".

If further users (e.g. a user C, not illustrated) join the conference by contacting user A, user A will either connect user Cto oneof theexisting mediaservers, or create interconnections between new MRFPs, if necessary.

In a second exampleof thisusecase, auser voting based interconnection process using D MS- based discovery is described. This use case is similar to the above use case. User Awill discover the avai lable MRFPs in the same fashion, using the DMS. However, user Awill inform user B about the available MRFPs and both users A, B will decide democratically which MRFPsto use in the conference service. The voting procedure may take place for instance in a web-based tool or by using the Graphical User Interface (GUI) of the users' communication applications (provided in the users' client). In athird exampleof thisusecase, a 3rd-party driven interconnection process using DMS-based discovery isdescribed. In thisusecase, athird party component (e.g. an enterprise server) will automatically assign the MRFPs used in a particular media session. Either user A, the administrator of the media session (e.g. conference), or the third party component will contact theDMS. Oncethethird party component has obtained the information of the MRFPs in the cloud network, it will arrange the necessary hierarchy to support the media session. The third party component may not be physically apart of the cloud provider's cloud network, !n contrast, in most cases the third party component will belong to user A's network, or, in case of an enterprise, thethird party component will reside in the enterprise network. In afourth exampleof thisusecase, a self-organizing interconnection process using D MS- based discovery is described. In thisusecase, user A will contact the DMSin order to obtain theinitial MRFP candidate for the conference service. User A will contact theDMSin a similar fashion asin the user-driven interconnection process described earlier. However, in this case, the user A will choose only one MRFP. Once theinitial MRFP has been chosen, user A will send the information to this initial MRFP about the rest of the users wanting to participate in the conference. The initial MRFP will then discover and interconnect all of theother MRFPsof the conference through theDMSand inform these M RFPs about theuserswho need to be connected to the conference. In particular, theinitial M RFP may ask the DMSfor information relating to theother MRFPsand then interconnect theMRFPsthus creating a communication path. This process continues until all the users of the conference have been joined to the conference.

In the particular use case described, initially comprising only two users(user A and user B), the initial MRFP will directly contact user Band will create the media links between both users (i.e. between their respective client).

In another scenario, it is assumed that there are three users, A, B, and Cthat want to establ i sh a confer en ce sessi on .

Step 1: User A is aware of all the users (i.e. aware of itself, B, and C) that are to be joined into the conference session. Step 2: User A contacts the DMSin order to discover a MRFP, for example located close to itself.

Step 3: The DM S returns the address of the most suitable MRFP to serve user A. Alternatively, the DMSmay return multiple alternative M RFPs, in which case user A needs to select one of them. The returned or selected RFP of user A is henceforth referred to as MS-A. Step 4: User A contacts MS-A and sends, to MS-A, the contact information of all the users that are to be connected to the conference.

Step 5: S-A figures out certain relevant information about the users, such as the geographical locations of the users, the codecs they use, and so forth. In some cases, this information was provided to it by user A. In other cases, MS-A may for instance directly contact the users A, B, Cto obtain the information, or it may contact a database maintaining this information.

Step 6: Having obtained the required information about the users (A, B, and C), MS- A determines the best configuration of MRFPs to serve all of these users A, B, C. As an example, if all of the users A, B, Care using different video codecs, MS-A may invite additional RFPs to the conference session so that transcoding between all the video codecs can be performed. In thiscase, MS-A attempts to discover two additional MRFPs, MS-B, and MS-C located close to users Band C, respectively, and establishes interconnections between the three MRFPs. Optionally, MS-A may also add afourth MRFP, MS-D that is not connected to any user, but only to the other MRFPs. Such a MRFP (MS-D) may perform operations such as audio and video mixing in the conference. Finally, MS-A establishesthe links between user A and itself, user Band MS-B, and user Cand MS-C. The appropriate number of MRFPs and thetopology between them depends on various factors such asnumber of users in the conference, the locations of the users, the amount of processing required by the media streams, the codecs used by the users, and so forth.

Next, asecond use case will be described. In the examples of this second use case described below, user A and B create a conference session between them using multi cast -based MRFP discovery. The MRFPs exchange information about their locations through amulticast group. TheusersAand B subscribe to thisgroup in order to obtain information about MRFPs.

In afirst example of this use case a user-driven interconnection process based on multicast discovery isdescribed. User A isassumed to bean administrator of the conference session. As the administrator, user A will first subscribe himself to the multicast channel to discover the available media servers in the cloud communication system 10. It isassumed that the user A has pre-loaded themulticast addressin his communication device. As an alternative, the user A may obtain that information for instancefrom a trusted website (e.g. from an enterprise intranet page).

Further, it isassumed that there are multiple multicast channels to which the user A can subscribe. The multicast channels may be divided based on some specific char act eristics of the media servers. For example, a particular multicast channel may be used for finding a media server having character! sties making it suitable for use in conference sessions. Themulticast channels may thus be divided in the

characteristics of the media servers, for instance, there may be a multicast channel for the medi servers which support only video, another multicast channel for the media servers which support video and audio, another multicast channel for the media servers which support an specific codec etc. Then, users may subscribe to the channel which is most suitable for their specific service.

Once the user A has obtained the available media servers, he will unsubscribe from themulticast channel and he- as the conference administrator - will choose the media servers to be used for the media session, and will contact, using I P protocols (e.g. SI P, HTTP, XM PP etc.), those media servers to create the interconnections between them. The sending of such protocol messages may be triggered by the user by means of a user interface. In asecond exampleof thissecond usecaseauser voting based interconnection process based on multicast discovery is described. This use case is similar to the previous case described above; user A discovers the available media servers in the samefashion. However, user A will inform user B about the available media servers and both userswill decide democratically which medi servers to use in the conference service.

In athird exampleof thissecond use case athird-party driven interconnection process based on multicast discovery isdescribed. In this third exampleof the second use case, athird party component (e.g. an enterprise component, such as an enterprise server) will automatically assign the media servers used in aparticular media session, e.g. a conference service. Either user A, who is the administrator of the conference service, or thethird party component will subscribe to the appropriate multicast channel. Once thethird party component has obtained information about media servers that are available in the cloud communication system 10, it will arrange the necessary delivery hierarchy between users A and Bto support their media session.

In a fourth example of this use case, illustrated in figures, a self -organizing interconnection process based on multicast discovery isdescribed. In this exam pie, user A (also denoted client A and indicated by reference numeral 15 in thefigure) will subscribe to an appropriate multicast channel (indicated by dashed lines in thefigure 5) to obtain an initial MRFP candidate for the conference service.

Once the first RFP has been chosen for the conference service, user A will send the information about the rest of the users (only one such user indicated in figure 5: client B, also indicated by reference numeral 16) wishing to participate in the conferenceto this MRFP. Thisinitial MRFPwill then discover and interconnect the other media servers to be used in the conference through subscribing to the same multicast channel as user A. Further, the initial RFPwill inform the other RFPs about the users who need to be connected to the conference service.

This process continues until all participants have joined the new conference service.

In the example, since initially comprising only two users (client A and client B in figures), theinitial MRFPwill not need to subscribeto any multicast channel.

Instead, it will directly contact user B (reference numeral 16) and create the media links between users A and B.

Next, a third use case will be described, wherein a conference service is created using point-to-point cloud configuration. In the examples of thisthird use case described below, user A is connected through a permanent link to her First-Hop RFP (FH- RFP) and user Bto another FH-M RFP. Figure 6 illustratesthis use case, and in particular a point-to-point cloud topology.

In afirst example of thisthird use case, a user-driven interconnection process based on point-to-point discovery is used. Asdescribed earlier, the starting point for the point-to-point discovery based user-driven M RFP interconnection process is that user A is connected through a permanent link to her FH-M RFP ( RFP denoted 14 ₄ in figure6) and user B to another FH-MRFP (MRFP denoted 14i in figureG). In this use case, it is assumed that user A isthe administrator of the conference service. The end-to-end mediapaths (media channel indicated in thefigure6 by letter "M") between the users and the MRFPscan be defined either by the different MRFPsor by the user A, In the latter alternative, the user A can inform her FH- RFP (MRFP 14 ₄ ) about the interconnections needed for her service. User A can discover the different M RFPs in the cloud network 20, 21 by using the methods described earlier, e.g. DMS and/ or multicast. Once user A obtains the available MRFPs, she can order her FH- M RFP (M RFP 14 ₄ ) to create the interconnections between them.

In asecond exampleof thisthird use case, a user voting based interconnection process based on point-to-point discovery is used. This example is very similar to the previous example. User A will discover the available MRFPs in the same fashion. However, user A will inform user B about the available MRFPs and both users will decide democratically which RFPsto use in the conference service. After that, user A and B will inform their corresponding FH-M RFPs about the interconnections between them. In athird exampleof this use case, a 3rd-party driven interconnection process based on point-to-point discovery isused. In thisexample, athird party component will automatically assign the MRFPs used in aparticular mediasession. Thethird party component will inform either user A, who isthe administrator of aconference, or user A's FH- RFP about the available MRFPs in the cloud network. Once the FH- M RFP has obtained the information about the MRFPs that are to be used, it will arrange the necessary delivery hierarchy to support the media session informing the other FH-M RFPs in the cloud network.

In afourth exampleof thisusecase, a self-organizing interconnection process based on point-to-point discovery isused. In thisexample, user A will contact her permanently-connected FH-M RFP and will send the information of the rest of the usersin the conference to her FH-MRFP. User A'sFH-MRFPwill then discover the other FH-M RFPs of the conference using any of the methods as described, e.g. DMS or multicasting.

In this exemplary case, since there were initially only two users, the initial RFP will discover the FH-M RFP of user Bor will try to di ectly contact user B to create the media links between the users A and B. Several ways have been described on how the RFPs are discovered and how the interconnections between them are organized. In the following the creation of MRFPs (i.e. mediaserver virtual machines, also denoted mediaserver instance) will be described. The creating of the MRFPs and keeping a suitable number thereof, i.e. scaling the number of MRFPs up and down, will be described.

It isthe responsibility of thecloud service provider to createthe initial set of MRFPs (mediaserver virtual machines) in the datacenters that thecloud service provider is operating. One among many potential initial M RFP deployment strategies may be to simply create a single RFP, or a cluster of MRFPs, in every datacenter that the cloud service provider is operating.

S nee the initial set of deployed RFPs may run out of capacity as a result of a high number of ongoing multimedia sessions, a mechanism is provided to create new MRFPs whenever deemed necessary. The mechanism described is self-replication. In self-replication, a MRFP that isabout to reach itsmaximum capacity, e.g. in termsof CPU (Central Processing Unit) load, memory, storage space, or network bandwidth, will autonomously trigger the creation of anew RFP. To achieve this, the MRFP asksthe cloud operating system (e.g. an Open Stack system), which is part of the cloud communication system 10, to spawn new MRFP image, virtual machine image, in the same datacenter in which it is located. Before asking the cloud operating system to spawn a new image, the M RFP may check whether there are other RFP with idle capacity present in the same datacenter. Such check may be done using the MRFP discovery mechanisms described earlier (e.g. DMSor multicast). If existing MRFPs with idlecapacity arediscovered in thesame

datacenter, the idlecapacity in them is preferably used before creating new RFPs. A MRFP may also autonomously decide to scaledown, that is, remove itself from the cloud network 20, 21. Such scaling down action can betriggered for instance if the RFP has been idle for some pre-configured amount of time. The operator of cloud network 20, 21 may specify certain constraintsto scaling down. As an example, the operator may specify that only MRFPs that have been created as a result of an autonomous scaling up decision can be scaled down and that RFPs that were created during the initial deployment phase may never be scaled down. If such initially created MRFPswereallowed to scaledown, it might happen that after some period of idleness globally in the cloud network 20, 21, all of the MRFPs would be removed as a result of autonomous scaling down decisions.

Finally, new MRFPs may also autonomously be created in datacentersthat did not previously have any MRFPs. This is possible if information about datacentersand their locations is maintained in adatabasesuch astheDMS. As an example, amedia server that has experienced a high number of users connecting to if from relatively distant locations (the users connect to this MRFP since they consider it to be the geographically closest MRFP for them), the media server may check whether there exists a datacenter located closer to the users than thedatacenter in which the MRFP itself is running. If such a datacenter isdiscovered, the M RFP may ask (e.g. a particular function/ node in) the distributed cloud communication system 10 to create anew MRFP (or MRFP cluster) in thedatacenter. This newly created MRFPcan then be used to serve new users in the future.

Whenever anew M RFP is created, it needs to register with the D Sor join the multicast group and let the other RFPsknow about its existence. Further, whenever existing MRFPs are removed, they need to de-register from the DMSor inform the multicast group that they will cease to exist.

Irrespective of which mediaserver discovery mechanism (DMS, multicast, or point- to-point) isused, it may be beneficial to implement aselection of which mediaserver to use from fhesef of discovered media servers in aprobabilisficfashion. In other words, if mediaserver selection is based for instance on load of the mediaserver, the user should pick one media server among a number of least loaded media servers at random. Such probability- based mediaserver allocation may be implemented in order to prevent situations wherein multiple users executing the mediaserver discovery processat the same time end up choosing thesame (least loaded) media server and thus overload that particular medi server.

Theexamplesdescribed above have assumed that amediasession is always

established between only two users and that the intention of these users to join the media session is known already when the session is being created. A slightly more complicated case is when additional users wish to join an ongoing media session. The first action such users need to take is discovering the ongoing mediasession, e.g. a conference. Different means to discover the ongoing mediasession can be envisioned. A first way of discovering the ongoing conference is to use a DM S implemented either as a server -based database or a DHT overlay among the media servers, or use a component similar to the D Sfor storing information about all ongoing media sessions. In addition, for each ongoing mediasession, the DMS(or similar

component) stores information about at least one media server carrying out media processing for that mediasession. In order to query the DMS, the user needs to know the identifier of the mediasession which hewantsto join.

Further users joining the media session always contact the user acting asthe administrator of the media session. The administrator then interconnects the new users to the media servers. Alternati ely, the user may delegate the task of

interconnecting the users and the media servers to the joining user, to the FH- RFP of thejoining user, or to athird-party component.

The described ways of discovering the M RFPs and interconnecting selected ones is described further in thefollowing, with reference to figure?. Figure 7 is a flow chart illustrating steps of a procedure 100 that may be performed in accordance with the present disclosure. The procedure 100 may be implemented in a single node or functions performed by the procedure may be distributed to several nodes.

Box 101. A user wishesto join or establish a media session.

Box 102. In order to join or establish a media session, the user needs to discover one or more media servers. The user can discover media servers using one of three discovery mechanisms: point-to-point discovery (flow continuesto box 103), multicast discovery (flow continuesto box 104) or using DMSfor thediscovery (flow continuesto box 105).

Box 103. If point-to-point discovery isused, the user discoversan FH-MRFP and the flow then continuesto box 107.

Box 104. If multicast discovery isused, the user joins a native multicast group or an ALM distribution tree, and theflow then continuesto box 106.

Box 105. If a DM Sis used, the user queries the DMS (which may be distributed DMSorganized using a DHT overlay) to gather information about mediaservers, and theflow then continuesto box 109. Box 106. In box 106 the user gathers information about media servers from the multicast group, theflow then continues to box 109.

Box 107. In box 107, the user connects to an FH-MRFP, and theflow then continuesto box 108. Box 108. In box 108 the user gets information about media servers available in the system from the FH-MRFP, and theflow then continuesto box 109.

Box 109. In box 109, i respective of which discovery mechanism wasused, the user has finished gathering information about oneor more media servers.

Box 110. Having discovered oneor more media servers, the user selects one of the four mediaserver interconnection mechanisms: user-driven mediaserver

interconnection process (box 111), voting-based interconnection process (box 112), third-party-driven interconnection process (box 113) or self-organizing

interconnection process (box 114).

Box 111. In box 111, the user has chosen the user-driven mediaserver

interconnection process, and theflow then continuesto box 115.

Box 112. In box 112, the user has selected the interconnection process based on user voting, and theflow then continuesto box 115.

Box 113. In box 113, the user relies on the third-party-driven interconnection process, the flow then continuesto box 115. Box 114. In box 114, the user has chosen to rely on the self-organizing

interconnection process. Flow then continues to box 115.

Box 115. Finally, in box 115, all the required mediaserver interconnections have been created and the user is a part of amultimediasession.

Figures illustrates aflow chart over steps of a method in a node in accordance with the present disclosure. The method 30 may be performed in anode 15, 16; 14i, 14?, 14s, 144 for configuring a communication path for a media service. The

communication path is configured in acioud network 20, 21 comprising at least one media processing unit 14i, 142, 14a, 14 ₄ configured to handle media processing required by the media service. The node 15, 16; 14i, 142, 143, 14 ₄ is located along the communication path, The node 15, 16; 14 , 142, 14a, 14 ₄ could be seen as part of the communication path in that it is involved in receiving, transmitting and/or processing data packets of the media service. Thisisin contrast to prior art, wherein a centralized controller node is configured to set up a requested media service and is thus a separate node. Such prior art centralized controller node handles e.g. control signaling to media processing units of one or several media sessions and is not located along any communication path. The node 15, 16; 14i, 142, 14a, 14 ₄ may bean end user communication device 15, 16 or a media processing unit 14i, 142, 14a, 14 ₄ processing media streams for the media service. The method 30 comprises discovering 31 at least one media processing unit 14-i, 142, 14a, 14 ₄ by obtaining location information for the at least one media processing unit 14-1, 142, 14a, 14 ₄ . This discovering 31 may be done in one of several ways, as has been described.

The method 30 comprises configuring 32 the communication path between end user communication devices 15, 16 of the media service by interconnecting one or more of the discovered media processing units 14i, 142, 14a, 144. The configuring of the communication path may also bedonein variousways, ashavebeen described.

In an embodiment, the discovering comprises retrieving the location information from a database component 12, 13 storing and updating location information for all media processing units 14i, 142, 143, 14 ₄ in the cloud network 20, 21.

In an embodiment, the discovering comprises receiving the location information in a multicast channel.

In an embodiment, the node 15, 16 is configured with afirst-hop media processing unit (14i, 142, 143, 14 ₄ ) and wherein the discovering comprises obtaining the location information from thefirst-hop media processing unit 14i, 14?, 14a, 14 ₄ .

In an embodiment, the configuring comprises the node 15, 16 receiving user input selection of media processing units 14-i, 142, 14a, 14 ₄ and configuring the

communication path between the selected media processing units 14i, 142, 14a, 144.

In an embodiment, the node 15, 16 comprises an end user communication device 15, 16 and wherein theconfiguring comprisesaself-organizing interconnection process comprising the end user communication device 15, 16 connecting to an initial media processing unit 14i, 142, 14a, 14 ₄ , which in turn connects to another end user communication device or discoversat least one media processing unit 14i, 142, 14a, 14 ₄ to which is connects, the process being repeated by each connected media processing unit 14i, 142, 14a, 14 ₄ until all end user communication devices of users of the media service are connected to the media service.

In an embodiment, the node 15, 16; 14i, 142, 143, 14 ₄ comprises an end user

communication device 15, 16 and wherein the configuring comprises receiving, in the end user communication device 15, 16, votes from all end user communication devices regarding choice of media processing unit 14i, 142, 14a, 14 ₄ and

interconnecting media processing unit 14i, 142, 143, 14 ₄ receiving most votes such that all end user communication devices are interconnected.

In an embodiment, the method 30 comprises:

- detecting 33 that a capacity parameter for a media processing unit 14i, 142, 14a, 14 ₄ is above a threshold, and - providing 34 increased capacity by:

- creating anew media processing unit 14 , 142, 14a, 14 ₄ , or

- determining that another media processing unit 14i, 142, 14s, 14 ₄ has idle capacity and using the idle capacity for media processing.

In an embodiment, the method 30 comprises: - detecting 35 that a capacity parameter for a media processing unit 14-i, 142, 143, 14 ₄ is below a threshold or that the media processing unit 14i, 14?, 14a, 14 ₄ has been idle for apreconfigured period of time, and

- removing 36 the media processing unit 14-i, 142, 143, 14 ₄ .

In avariation of the above two embodiments, themethod 30 comprises providing information about creation and/ or removal of a new media processing unit 14-i, 142, 14a, 14 ₄ to a database component 12, 13 storing and updating location information for all media processing units 14i, 142, 143, 14 ₄ in the cloud network 20, 21.

Figure9 illustrates schematically anode 15, 16; 14i, 142, 143, 14 ₄ and meansfor implementing various embodiments of themethod of the present disclosure. The node comprises a processor 40 comprising any combination of one or more of a centra! processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit etc. capable of executing software instructions stored in amemory 41, which can thus be a computer program product 41. The processor 40 can be configured to execute any of the various embodiments of the method as described earlier, e.g. in relation to figures7and 8.

The memory 41 can beany combination of read and write memory (RAM) and read only memory (ROM). The memory 41 also comprises persistent storage, which, for example, can beany single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory. The memory 41 may comprise a computer program 42 for implementing embodiments of the method as has been described. Such computer program 42 may comprise one or several computer modules performing various functions.

A data memory 43 may also be provided for reading and/ or storing data during execution of software instructions in the processor 40. The data memory 43 can be any combination of read and write memory (RAM) and read only memory (ROM).

The node 15, 16; 14i, 14 , 143, 14 ₄ may also comprise an input/ output device 44 for receiving and transmitting data packets.

When the node 15, 16; 14-i, 142, 14s, 14 ₄ is a communication device handled by an end user, the node may comprise further components (not illustrated) such as user interface, display, antenna arrangements etc.

It is realized that when the node 15, 16; 14i, 142, 14a, 14 ₄ is a media processing unit, in particular amediaserver instance running in one virtual machinewithin adata center, devices such as input/ output devices are software implementations. That is, every virtual machine has a virtual network interface for input/ output. However, the physical server on which the irtual machines are running obviously needs to have physical input/ output device (physical network interface). Thevirtual machines are sharing the physical network interface, in known manner.

A node 15, 16; 14i, 142, 14a, 14 ₄ isthus provided for configuring a communication path for a media service is provided. The communication path isconfigured in acloud network 20, 21 comprising at least one media processing unit 14i, 142, 143, 14 ₄ configured to handle media processing required by the media service. The node 15, 16; 14i, 142, 14a, 14 is located along the communication path the node 15, 16; 14i, 142, 14s, 14 ₄ comprising a processor 40 and memory 41, the memory 41 containing instructions executable by the processor 40, whereby the node 15, 16; 14i, 142, 14a, 14 ₄ is operative to:

- discover at least one media processing unit 14i, 142, 14a, 14 ₄ by obtaining location information for the at least one media processing unit 14i, 142, 14a, 14 ₄ , and

- configure the communication path between end user communication devices 15, 16 of the media service by interconnecting one or more of the discovered media processing units 14i, 142, 14a, 14 ₄ .

In an embodiment, the node 15, 16; 14 , 142, 143, 14 ₄ isconfigured to discover by retrieving the location information from a database component 12, 13 storing and updating location information for all media processing units 14i, 142, 14a, 14 ₄ in the cloud network 20, 21. In an embodiment, the node 15, 16; 14 , 142, 14a, 14 ₄ isconfigured to discover by receiving the location information in a multicast channel.

In an embodiment, the node 15, 16 isconfigured with afirst-hop media processing unit 14i, 142, 143, 14 ₄ and configured to discover by obtaining the location information from thefirst-hop media processing unit 14-i, 142, 14a, 14 ₄ . In an embodiment, the node 15, 16 isconfigured to perform the configuring by receiving user input selection of media processing units 14i, 142, 14a, 14 ₄ and configure the communication path between the selected media processing units 14i, 142, 143, 14 ₄ .

In an embodiment, the node 15, 16 comprises an end user communication device 15, 16 configured to perform the configuring by a self-organizing interconnection process comprising the end user communication device 15, 16 connecting to an initial media processing unit 14-i, 142, 143, 14 ₄ , which in turn connects to another end user communication device or discoversat least one media processing unit 14i, 142, 14a, 14 ₄ to which is connects, the process being repeated by each connected media processing unit 14-i, 142, 143, 14 ₄ until all end user communication devices of users of the media service are connected to the media service. In an embodiment, the node 15, 16; 14i, 142, 14a, 14 ₄ comprises an end user

communication device 15, 18 configured to perform the configuring by receiving, in the end user communication device 15, 16, votes from all end user communication devices regarding choice of media processing unit 14i, 142, 143, 14 ₄ and

interconnecting media processing unit 14i, 142, 14.3, 14 ₄ receiving most votes such that all end user communication devices are interconnected.

In an embodiment the node 15, 16; 14i, 142, 14s, 14 ₄ is configured to:

- detect that acapacity parameter for a media processing unit 14i, 142, 143, 14 ₄ is above a threshold, and - provide increased capacity by:

- creating anew media processing unit 14i, 142, 143, 14 , or

- determining that another media processing unit 14i, 142, 14s, 14 ₄ has idle capacity and using the idle capacity for media processing.

In an embodiment the node 15, 16; 14i, 142, 14s, 14 ₄ is configured to: - detect that acapacity parameter for a media processing unit 14i, 142, 143, 14 ₄ is below a threshold or that the media processing unit 14i, 142, 14a, 14 ₄ has been idle for a preconfigured period of time, and

- remove the media processing unit 14i, 142, 14s, 14 ₄ .

I variations of the above two embodiments, the node 15, 16; 14i, 142, 14s, 14 is configured to provide information about creation and/or removal of anew media processing unit 14i, 142, 14a, 14 ₄ to a database component 12, 13 storing and updating location information for all media processing units 14i, 142, 143, 14 ₄ in the cloud network 20, 21.

The present disdosure lso encompasses a computer program product 41 comprising acomputer program 42 for implementing the methods as described above, and a computer readable means on which the computer program 42 is stored. The computer program product 41 may beany combination of read and write memory (RAM) or read only memory (ROM). The computer program product 41 may also comprise persistent storage, which for example can be any single one or combi nation of magnetic memory, optical memory or solid state memory.

The present disclosure thus comprises a computer program 42 for a node 15, 16; 14i, 142, 14s, 144 for configuring a communication path for a media service, the

communication path being configured i n a cloud network 20, 21 comprisi ng at least one media processing unit 14i, 142, 14s, 14 ₄ configured to handle media processing required by the media service. The node 15, 16; 14 , 142, 14a, 14 ₄ is located along the communication path. The computer program 42 comprises computer program code, which, when run on the node 15, 16; 14i, 142, 143, 14 ₄ causes the node 15, 16; 14 , 142, 14a, 144 to:

- discover at least one media processing unit 14-i, 142, 14s, 14 ₄ by obtai ni ng location i nformation for the at least one media processing unit 14i, 142, 14a, 14 ₄ , and

- configure the communication path between end user communication devices 15, 16 of the media service by interconnecting one or more of the discovered media processing units 14i, 142, 14s, 14 ₄ .

A computer program product 41 comprisi ng a computer program 42 as above, and a computer readable means on which the computer program 42 is stored is also provided. The computer program product, or the memory, thus comprises

i nstructions executable by the processor 40. Such i nstructions may be comprised in a computer program 42, or in one or more software modules or function modules.

An example of an i mplementation using function modules/ software modules is i llustrated in figure 10, i n particular i llustrati ng a node 15, 16; 14i, 142, 143, 14 ₄ comprising means, in particular function modules, for i mplementi ng embodiments of the method of the present disclosure. The node com prises means, i n particular a fi rst function module 51, for discoveri ng at least one media processi ng unit 14i, 142, 14s, 14 ₄ by obtai ni ng location i nformation for the at least one media processi ng unit 14i, 142, 143, 14 ₄ . The node comprises means, i n particular a second function module 52, for configuring the communication path between end user communication devices 15, 16 of the media service by interconnecti ng one or more of the discovered media processing units 14-t, 142, 14s, 14 ₄ . The node may comprise yet additional means, i n particular additional function modules, as indicated by the empty boxes of figure 10, for performing other steps of the method as described.

Thefunction modules 51, 52 can be implemented using software instructions such as computer program executing in a processor and/ or using hardware, such as application specific integrated circuits, field programmable gate arrays, discrete logical components etc. odifications of the disclosed embodiments and other embodiments will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that thedisclosure(s) is/ are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of this disclosure. Although specific terms may be employed herein, they areused in a generic and descriptive sense only and not for purposes of limitation.