Method, system and device for distrubuting and receiving the multicast data in the media gateway

0001This application claims a priority from the Chinese Patent Application No. <patcit id="pcit0001" dnum="CN200610140147"><text>200610140147.6</text></patcit>, filed with the Chinese Patent Office on Sep. 30, 2006 entitled "METHOD, SYSTEM AND APPARATUS FOR MEDIA GATEWAY TO TRANSMIT AND RECEIVE MULTICAST DATA", the contents of which are incorporated herein by reference in their entirety.

FIELD OF THE INVENTION

0002The present invention relates to the field of communication, and in particular, to a method, system, and apparatus for a Media Gateway (MG) to transmit and receive multicast data.

BACKGROUND

0003As shown in <figref idref="f0001">Figure 1</figref>, two key components exist in a packet-switched network: Media Gateway Controller (MGC) and Media Gateway (MG.). The MGC is responsible for the call control function, and the MG is responsible for the service bearer function. In this way, the call control plane is separated from the service bearer plane, the network resources are sufficiently shared, and equipment upgrade and service extension are simplified, and the development and maintenance costs are slashed.

0004The (media) gateway control protocol is a protocol mainly used for communication between the MG and the MGC. The currently prevalent (media) gateway control protocols include H.284/Gateway Control Protocol (MeGaCo) and Media Gateway Control Protocol (MGCP). The MGCP R1 protocol was formulated by the Internet Engineering Task Force (IETF) in October 1999 and revised in January 2003. The H.248/MeGaCo R1 protocol was formulated by the IETF and the International Telecommunications Union (ITU) in November 2000 and revised in June 2003. The H.248 R2 protocol was formulated by the ITU in May 2002 and revised in March 2004. The H.248 R3 protocol was formulated by ITU in September 2005.

0005Taking the H.248 protocol as an example, various resources on the MG are abstractly represented by terminals. Terminals are categorized into physical terminals and ephemeral terminals. Physical terminals are physical entities which exist semi-permanently, for example, Time Division Multiplex (TDM) channels. Ephemeral terminals represent the public resources which are requested temporarily and released soon after being used, for example, Real-time Transport Protocol (RTP) streams. Moreover, a root terminal is used to represent the entirety of the MG. The combinations among terminals are abstractly represented by contexts. A context may include multiple terminals. Therefore, topology is used to describe the interrelations between terminals. The terminal not related to other terminals is contained by a special context called "null".

0006Based on an abstract model such as the foregoing protocol, the call routing is actually an operation on the terminal and the context. Such operations are performed through Command Requests and Reply between the MGC and the MG. Command types include: Add, Modify, Subtract, Move, AuditValue, AuditCapabilities, Notify, and ServiceChange. Command parameters, also known as descriptor, are categorized into Property, Signal, Event, and Statistic. The parameters with service relevance are logically aggregated into a package.

0007Taking the IP multicast technology of sending services to type-D IP address (namely, multicast address) as an example, when the IP multicast technology enables the sender to send the same service content to one or more receivers, only one copy of the same content needs to be sent to the specified multicast address, thus reducing the load on the service sender and the transport network efficiently.

0008In order to obtain the multicast contents, the content receiver (namely, the user) joins a service multicast group, for example, by using the Internet Group Message Protocol (IGMP), to require the adjacent router to send service contents to the content receiver. Routers interact with each other through a multicast routing protocol, for example, Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol, to create a multicast forwarding path. In this way, the multicast service contents can be sent to the content receiver from the multicast source along the multicast forwarding path.

0009When a service stream is transferred through the multicast technology, the service sender needs to send only one service stream regardless of the number of receivers. Only one data stream is generated along the transmission path from sending point of the multicast data to the transfer point of the receiver. Obviously, the multicast technology reduces the load of the service sender (service provider), and makes the most of network resources.

0010The inventor finds out that on the path of propagating the current multicast content, the entity for receiving and forwarding the multicast service is a router. When different networks are interconnected, an MG is usually required. However, the action of an MG is not identical to the action of a router: first, the MG is unable to receive multicast routing messages such as PIM-SM, and hence the multicast data is unable to pass through the MG. The H.248 protocol is increasingly becoming a mainstream protocol for bearer control, and needs to support multicast media and signaling forwarding.

SUMMARY

0011The present invention provides a method, system and apparatus for an MG to transmit and receive multicast data.

0012A method for an MG to receive multicast data in an embodiment of the present invention includes: the MG receives a multicast-related indication from the MGC, and reports the relevant information to the router in the network at the multicast source side according to the indication, and requests to join the multicast group; the MG receives the multicast data transmitted by the multicast source.

0013A method for an MG to transmit multicast data according to an embodiment of the present invention includes the following: <ul id="ul0001" list-style="none" compact="compact"><li>the MG receives the multicast-related indication from the MGC; and</li><li>the MG transmits the corresponding multicast data to the users in the network at the receiver side in the form of multicast according to the indication.</li></ul>

0014A system for an MG to receive multicast data according to an embodiment of the present invention includes: <ul id="ul0002" list-style="none" compact="compact"><li>an MGC, which includes a sending unit adapted to send a multicast-related indication to an MG when receiving a request of joining or quitting the multicast group from the user; and</li><li>the MG, which includes a receiving unit adapted to report the relevant information to the router in the network at the multicast source side according to the indication of the MGC, request to join the multicast group, and receive the multicast data.</li></ul>

0015A system for an MG to transmit multicast data according to an embodiment of the present invention includes: an MGC, which includes: <ul id="ul0003" list-style="none" compact="compact"><li>a sending unit, adapted to send a data-related indication to the MG in the form of multicast; and</li><li>an MG, which includes a transmitting unit adapted to transmit the specified data to the user in the form of multicast according to the indication of the MGC.</li></ul>

0016An MGC according to an embodiment of the present invention includes a sending unit, adapted to send a multicast-related indication to the MG when receiving a request of joining or quitting the multicast group from the user.

0017An MG according to an embodiment of the present invention includes a receiving unit, adapted to report relevant information to the router in the network at the multicast source side according to the indication of the MGC, request to join the multicast group, and receive the multicast data.

0018Another MGC according to an embodiment of the present invention includes a sending unit, adapted to send to the MG a relevant indication of transmitting data in the form of multicast.

0019Another MG according to an embodiment of the present invention includes a transmitting unit, adapted to transmit the specified data to the user in the form of multicast according to the indication of the MGC.

0020A method, system and apparatus for an MG to receive multicast data are provided in an embodiment of the present invention, where the MGC sends a multicast-related indication to the MG. Afterward, the MG reports multicast memberships to the router in the network at the multicast source side according to the indication of the MGC. Therefore, the MG joins or quits the multicast group as a user, and receives multicast data. The indication includes several contents extended in an embodiment of the invention in order to enable the MG to receive multicast data.

0021A method and a system for an MG to transmit multicast data are provided in an embodiment of the present invention, where the MGC sends a multicast-related indication to the MG. Afterward, the MG acts as a multicast source to transmit the corresponding service data to the users in the network at the receiver side in the form of multicast according to the indication of the MGC. The indication includes several contents extended in an embodiment of the invention in order to enable the MG to transmit multicast data.

0022The foregoing two types of methods and systems may be combined to interconnect the multicast path between networks, thus meeting requirements of various applications more flexibly. Moreover, the MG device does not need to be updated in the embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

0023<figref idref="f0001">Figure 1</figref> shows a structure of a packet-switched network in the prior art;

0024<figref idref="f0001">Figure 2</figref> is a flowchart of a method for an MG to receive multicast data according to an embodiment of the present invention;

0025<figref idref="f0002">Figure 3</figref> shows a process of implementing multicast query events based on the H.248 protocol according to an embodiment of the present invention;

0026<figref idref="f0002">Figure 4</figref> shows a process of an H.248 user reporting multicast memberships proactively according to an embodiment of the present invention;

0027<figref idref="f0003">Figure 5</figref> shows a process for an MG to receive a query message and report the query result according to an embodiment of the present invention;

0028<figref idref="f0003">Figure 6</figref> shows a structure of a system for an MG to receive multicast data according to an embodiment of the present invention;

0029<figref idref="f0004">Figure 7</figref> is a flowchart of a method for an MG to transmit multicast data according to an embodiment of the present invention;

0030<figref idref="f0004">Figure 8</figref> shows a process of transmitting multicast data based on the H.248 protocol according to an embodiment of the present invention;

0031<figref idref="f0005">Figure 9</figref> shows a structure of a system for an MG to transmit multicast data according to an embodiment of the present invention;

0032<figref idref="f0005">Figure 10</figref> shows an application scenario of a method instance according to an embodiment of the present invention; and

0033<figref idref="f0006">Figure 11</figref> is a flowchart of a method instance according to an embodiment of the present invention.

DETAILED DESCRIPTION

0034In an embodiment of the present invention, a package is extended in the H.248 protocol to enable the MG to receive and transmit multicast data. For example, the package is named "Multicast Indication Package"; packet ID: mip, (0x0001); version: 1. The multicast indication package includes: an indication signal, and an event.

0035In order for an MG to receive multicast data, a method for an MG to receive multicast data is provided in an embodiment of the present invention. As shown in <figref idref="f0001">Figure 2</figref>, the method includes the following steps:

0036S11: The MGC sends a multicast-related indication to the MG.

0037S12: According to the indication of the MGC, the MG reports the relevant information (for example, multicast membership) to the router in the network at the multicast source side, and requests to join the multicast group. The MG retrieves the user membership information from the indication sent by the MGC, processes the information, and reports the multicast membership to the router in the network at the multicast source side. After receiving the multicast membership, the network at the multicast source side adds the MG as a member of the multicast group, or modifies the membership information, and then sends multicast data to the MG.

0038S 13: The MG receives the multicast data transmitted by the multicast source.

0039Furthermore, in order for the MG to be able to process the message of querying multicast memberships sent by the router, the present invention defines query events and indication signals, as described below.

0040The query event is described below.

0041An event (named "Multicast Membership Querier", for example) may be defined. Through the event, the MG may report the receiving of the multicast membership query message to the MGC. After the MG receives a relevant multicast membership query message, the MG returns the multicast policy information stored locally in response to the multicast membership query message, where the multicast policy information stored locally may be the policy sent by the MGC previously; or the MG requests relevant decision from the MGC, and the MG reports the multicast query event message to the MGC through a Notify command. Meanwhile, additional parameter information (for example, protocol version supported by the router, querier robustness, query interval, multicast address and source address) is attached to the reported event. Event name: Multicast Membership Querier; event ID: mmq, (0x0002); definition domain: this event may be sent by the MGC to the MG, or preset on the MG. The event is effective on the whole MG ROOT or certain terminals on the MG.

0042This event is sent from the MGC to the MG without carrying any parameter. The contents carried in the multicast query event message reported by the MG to the MGC include one of the following items: <ol id="ol0001" compact="compact"><li>(1) Querier's Protocol Version: This parameter carries the version information of the multicast management protocol (for example, IGMP) run by the querier in the network, its valid values include: 1, 2, and 3, and the default value is 3. This parameter value depends on the received query message: if the length of the received IGMP query message is 8 bytes and its Max Resp Code is 0, the version is 1; if the length of the received IGMP query message is 8 bytes and its Max Resp Code is not 0, the version is 2; if the length of the received IGMP query message is greater than or equal to 12 bytes, the version is 3.</li><li>(2) Querier's Robustness Variable: This parameter carries the robustness variable value of the querier, and indicates the count of the querier sending query messages, with a view to adjusting the expected packet loss ratio in the network. Neither 0 nor 1 is allowed as a value of this parameter. The default value of this parameter is 2.</li><li>(3) Querier's Query Interval Code: This parameter carries the value of the interval of the querier sending query messages. The default value of this parameter is 125 seconds.</li><li>(4) Query Number of Sources: This parameter carries the number of the specified source addresses in the query message. In the case of universal query and specific group query, the value of this parameter is 0.</li><li>(5) Query Source Address: This parameter carries a list of source addresses specified in the query message, where the number of the specified source addresses is the same as that of the "Query Number of Sources" mentioned above.</li><li>(6) Query Group Address: This parameter carries the multicast group address specified in the query message. In the case of universal query, this parameter is null; in the case of querying membership of a specific multicast group, this parameter carries the specified multicast address.</li></ol>

0043<figref idref="f0002">Figure 3</figref> shows the process of implementing a multicast query event based on the H.248 protocol (the command request and the response mechanism of the H.248 protocol are omitted in <figref idref="f0002">Figure 3</figref>). The process includes the following steps:

0044Message 1: The MGC sends an "IGMP query event" to the MG, without carrying any parameter. This event may be carried in an Add or Modify command to the whole MG (ROOT) when the MG creates a terminal, or sent to an existing terminal.

0045Message 2: The MG receives the query message of the multicast router.

0046Message 3: The MG obtains the relevant multicast query message according to the received query message, and reports such information to the MGC through the "IGMP query request" event (for example, Notify command) sent by the MGC in message 1.

0047The indication signal is described below.

0048When the MGC receives the request message of the user joining or quitting the specific multicast group, the MGC sends a multicast-relevant indication to the MG. Signal name: Multicast Group Membership; signal ID: mgm, (0x0003); description: This signal is used for the MGC to send the relevant multicast group membership information to the MG. It may be complete multicast group membership information of the user, or supplement or modification to the current multicast group membership. Definition domain: This event may be effective on the whole MG ROOT or certain terminals on the MG.

0049The contents carried by the indication signal include at least one of the following items: <ol id="ol0002" compact="compact"><li>(1) Multicast Address: This parameter carries the address of the multicast group that the user needs to join. The format of the parameter is a type-D address, and its value range is 224.0.0.0-239.255.255.255.</li><li>(2) Record Type: This parameter indicates the type of the record, and may have one of the following values depending on the specific situation: <ul id="ul0004" list-style="none" compact="compact"><li>The record of the complete subscription state of the user - Current-State Record comes in two circumstances: <ol id="ol0003" compact="compact"><li>i. MODE_IS_INCLUDE: For the specified multicast address, the filtering mode is INCLUDE; and the subsequent Source Address parameter includes a list of the corresponding source addresses. INCLUDE indicates receiving of only the data sent from the specified source address.</li><li>ii. MODE_IS_EXCLUDE: For the specified multicast address, the filtering mode is EXCLUDE; and the subsequent Source Address parameter includes a list of the corresponding source addresses. EXCLUDE indicates receiving of only the data sent from all addresses except the specified source address.</li></ol></li><li>For a specified multicast address, when the filtering mode changes, the sent message is Filter-Mode-Change Record, which also comes in two circumstances: <ul id="ul0005" list-style="none" compact="compact"><li>iii. CHANGE_TO_INCLUDE_MODE: For the specified multicast address, the filtering mode changes to INCLUDE; and the subsequent Source Address parameter includes a new list of source addresses.</li><li>iv. CHANGE_TO_EXCLUDE_MODE: For the specified multicast address, the filtering mode changes to EXCLUDE; and the subsequent Source Address parameter includes a new list of source addresses.</li></ul></li><li>For a specified multicast address, when the source address changes (namely, differs from the current filtering mode), the sent message is a Source-List-Change Record, which also comes in two circumstances: <ul id="ul0006" list-style="none" compact="compact"><li>v. ALLOW_NEW_SOURCES: For a specified multicast address, the Source Address parameter includes the source addresses expected by the user to receive. If this change occurs on the source list of an INCLUDE mode, the addresses in the Source Address are added into the existing list; if the change occurs on the source list of the EXCLUDE mode, the addresses in the Source Address are deleted from the existing list.</li><li>vi. BLOCK_OLD_SOURCES: For a specified multicast address, the Source Address parameter includes the source addresses not expected by the user to receive. If this change occurs on the source list of an INCLUDE mode, the addresses in the Source Address are deleted from the existing list; if the change occurs on the source list of the EXCLUDE mode, the addresses in the Source Address are added into the existing list.</li></ul></li></ul></li><li>(3) Number of Sources: This parameter carries the number of the specified source addresses in the report message.</li><li>(4) Source Address: This parameter may be in the form of a list, and carries 0-N IP unicast addresses (N is consistent with the number of sources). This parameter may be used together with the filtering mode to indicate whether the user expect or not expect to receive the multicast data sent from the specific source address. If the report message corresponds to a report or response of IGMP V3, this parameter is carried; if it corresponds to IGMP V1 or V2, this parameter may be excluded.</li><li>(5) Send Delay: This parameter carries the maximum delay of the MG sending a report message. The MGC selects a delay time randomly between 0 and the maximum value according to the allowed maximum delay information, and the delay time is carried in the Send Delay parameter and sent to the MG. The MG sends a report message once the delay exceeds the time specified in this parameter. When the user sends a membership to join or quit a multicast group proactively, this parameter may be set to 0, namely, the report message is sent immediately after the MG receives the parameter information. The default value of this parameter is 10s.</li><li>(6) Whether Stop Sending Membership Report: The MG sends a report to the multicast address readily to be reported. If the MG receives a report message of other host memberships, this parameter decides whether to stop the delay counter without sending any report message. This parameter is of the Boolean type, and possible values are: <ol id="ol0004" compact="compact"><li>(i) ON (enabling this function, namely, once receiving a report message of other memberships, stopping the delay counter without sending any report message);</li><li>(ii) OFF (disabling the function, without handling other membership reports received).</li></ol> The default value of this parameter is ON. In IGMP V3, the host is unable to receive the report message from other hosts, and this parameter is meaningless. The IGMP V3 does not support this function.</li><li>(7) Automatic Reply Membership Query: This parameter decides whether to report the request-related policy to the MGC after the MG receives the IGMP query message from the router. That is, after receiving the IGMP query message, the MG may report to the MGC and request the relevant multicast relation information to send the response message, or send a response message proactively according to the multicast-related information stored on the MG without reporting to the MGC. This parameter is of the Boolean type, and possible values are: <ol id="ol0005" compact="compact"><li>(i) ON (enabling this function, namely, once receiving a membership query message from the MGC, the MG sends a response message proactively according to the stored information);</li><li>(ii) OFF (disabling this function, namely, after receiving a query message, the MG reports to the MGC and requests the relevant multicast policy information).</li></ol> The default value of this parameter is ON. </li><li>(8) Indication Triggering Reason: This parameter carries the reasons for sending the indication, including but not limited to: the indication triggered by receiving of the query event reported by the MG, and the indication sent proactively after the user subscription state changes.</li><li>(9) Purpose of Indication: This parameter includes but is not limited to, the indication on the previous state of the user, the indication on the current state, or the indication on only the state change part of the user.</li></ol>

0050Another parameter indicative of robustness variable of the report message may exist. Through this parameter, the MGC indicates the times of the MGC sending the report messages in order to control the reliability of message transmission. This parameter may be sent by the MGC to the MG, or preset on the MG.

0051The MGC sends a membership indication to the MG in two modes.

0052When the multicast membership of the user changes, the MGC sends membership information to the MG proactively, and the MG needs to send the information about the multicast membership change to the multicast router.

0053The first mode is as follows: <ul id="ul0007" list-style="none" compact="compact"><li>the MGC sends the current complete state information of the user to the MG; and</li><li>the MG compares the current state information of the user with the previous state information to obtain the changed membership information, and sends the change information to the multicast router.</li></ul>

0054The second mode is as follows: <ul id="ul0008" list-style="none" compact="compact"><li>the MGC sends only the membership change information of the user to the MG, and the MG may send such information to the multicast router directly; and</li><li>the foregoing two modes are based on the assumption that the MG retains the previous membership information of the user. If the MG does not retain such information, the MGC may send the old state information to the MG.</li></ul>

0055When receiving the query event reported by the MG, the MGC indicates the membership state information of the user to the MG. The MG needs to send the current membership information of the user to the multicast router.

0056The first mode is as follows: <ul id="ul0009" list-style="none" compact="compact"><li>the MGC sends the current complete state information of the user to the MG; and</li><li>the MG may send such information to the multicast router directly.</li></ul>

0057The second mode is as follows: <ul id="ul0010" list-style="none" compact="compact"><li>the MGC sends only the membership information change of the user to the MG, and the MG combines the user state change information with the previous state information to obtain the current complete membership information of the user, and then sends such information to the multicast router.</li></ul>

0058Likewise, the foregoing two modes are based on the assumption that the MG retains the previous membership information of the user. If the MG does not retain such information, the MGC may send the old state information to the MG.

0059The process related to the indication signal is illustrated below. <ol id="ol0006" compact="compact"><li>1) <figref idref="f0002">Figure 4</figref> shows a process where an H.248 user reports the multicast membership proactively (the command request and the response mechanism of the H.248 protocol are omitted in <figref idref="f0002">Figure 4</figref>). The process includes the following steps: <ul id="ul0011" list-style="none" compact="compact"><li>Message 1: When the H.248 user wants to join a multicast group proactively, the MGC sends the multicast group membership signal to the MG, with the relevant multicast parameter information carried in the signal. The multicast group membership may be sent to the whole MG (ROOT) through an Add or Modify command, or sent to an existing terminal.</li><li>Message 2: According to the multicast group membership information obtained from the MGC, the MG sends an IGMP message to the multicast router proactively to report its membership.</li></ul> If the existing multicast membership needs to be modified, the process is similar. </li><li>2) When the H.248 user wants to quit a multicast group, the MGC analyzes the version information of the current querier. If the version is 1, no report message is sent. If the version is not 1, the MGC sends the filtering information of the multicast address and the relevant source address to the MG, where the filtering mode is set to INCLUDE, the source address list is empty, and the delay counter is 0; the filtering information of the multicast address and the relevant source address may also be preset on the MG (where the filtering mode is set to INCLUDE, the source address list is empty, and the delay counter is 0). That is, if the version is not 1, the MG sends a quit report message to the adjacent router proactively to quit a multicast group.</li><li>3) <figref idref="f0003">Figure 5</figref> shows a process where the MG receives a query message and reports the message (the command request and the response mechanism of the H.248 protocol are omitted in <figref idref="f0003">Figure 5</figref>). The process includes the following steps: <ul id="ul0012" list-style="none" compact="compact"><li>Message 1: The MG receives the multicast membership query message from the multicast router.</li><li>Message 2: The MG obtains the relevant multicast query message according to the received query message, and reports such information to the MGC through a Notify command.</li><li>Message 3: The MGC sends a Reply carrying the corresponding multicast membership information to the MG according to the relevant multicast information.</li><li>Message 4: According to the multicast group membership information obtained from the MGC, the MG sends an IGMP message to the multicast router proactively to report its membership.</li></ul></li></ol>

0060The reporting action in message 2 is optional. That is, if the parameter (7) "Automatic Reply Membership Query" is set in the signal previously sent by the MGC, after receiving the IGMP query message of the router, the MG may report to the MGC and request the relevant multicast relation information to send the response message, or send a response message proactively according to the multicast-related information stored in the MG without reporting to the MGC. Accordingly, message 3 is optional.

0061An embodiment of the present invention provides a system for an MG to receive multicast data, and provides specific devices in such a system. As shown in <figref idref="f0003">Figure 6</figref>, the system includes: an interconnected MGC (namely, the MGC corresponding to the system for an MG to receive multicast data herein), and an MG (namely, the MG corresponding to the system for an MG to receive multicast data herein). The MG includes: a receiving unit, a multicast query event reporting unit and a responding unit.

0062The receiving unit is adapted to: report relevant information (for example, multicast membership) to the router in the network at the multicast source side according to the indication of the MGC, request to join the multicast group, and receive the multicast data.

0063The multicast query event reporting unit is adapted to: report the multicast query event message to the MGC, after the MG receives a multicast membership query message from the router in the network at the multicast source side.

0064The responding unit is adapted to send a membership report message to the query router by using the current multicast policy information.

0065The MGC includes a sending unit, and a multicast query event processing unit.

0066The sending unit is adapted to send a multicast-related indication to the MG when receiving a request of joining or quitting the multicast group from the user.

0067The multicast query event processing unit is adapted to retrieve the multicast-related information in the network adjacent to the network of the user from the message, and send multicast policy information to the MG accordingly, after receiving a multicast query event message.

0068In order for the MG to transmit the specified multicast data in the form of multicast, a method for an MG to transmit multicast data is provided in an embodiment of the present invention. By extending the H.248 protocol, the MGC sends the relevant policy information to the MG. Therefore, the MG may act as a multicast source to send data to a specified multicast address. On the one hand, the MG may forward the multicast data received from another multicast address, thus supporting interconnection of the multicast path. On the other hand, the MG may transmit the data on the specified path. As shown in <figref idref="f0004">Figure 7</figref>, the process includes the following steps:

0069S21: The MGC sends a multicast-related indication to the MG.

0070An indication signal is extended in the foregoing multicast indication package, for example, a signal named "Multicast Transmit Request". Through the indication signal, the MGC instructs the MG to act as a multicast transmitting source to play the media data on the specified path, or use the media stream received by the MG as a multicast medium for transmitting. Signal name: Multicast Transmit Request; signal ID: mtr, (0x0004); description: This signal is used for the MGC to send the relevant multicast service transmitting information to the MG. Definition domain: This event may be effective on certain terminals on the MG. This signal may be sent by the MGC to the MG, or preset on the MG. This signal may be carried in the Add command to the terminal when the MG creates a terminal, or sent to an existing terminal through a Modify command.

0071The Multicast Transmit Request carries the source of the played media stream. The source of the media stream may be media received by other terminals in the MG (for example, multicast service, for the purpose of implementing service routing and forwarding), or the media whose address and source are specified separately and used as a multicast data source for transmitting. The Multicast Transmit Request may also carry the multicast address of the multicast data sent by the MG. Moreover, the MG needs to allocate an address for sending service streams, namely, send the multicast service stream by using the allocated address and port as the source address and port of the service stream, and using the multicast address as a destination address to transmit services. After finishing the foregoing operations, the MG may feed back the operation result to the MGC. The operation result carries the relevant information, for example, the allocated address and port for forwarding services.

0072The contents carried in the indication signal include at least one of the following items: <ol id="ol0007" compact="compact"><li>(1) MulticastAddr This parameter includes the multicast address which needs to transmit multicast services. The format of the parameter is a type-D address, and its value range is 224.0.0.0-239.255.255.255. </li><li>(2) DataSourcelnfo This parameter includes the source information of the data to be transmitted in the multicast service. The source information may be the media received by other terminals in the MG, or the media whose address and source are specified separately (for example, URI format). This parameter may also include port information of the multicast address. </li></ol>

0073S22: The MG resolves the indication sent by the MGC.

0074The MG resolves the indication sent by the MGC and obtains the multicast address and/or source information of the transmitted data.

0075S23: According to the indication of the MGC, the MG transmits the corresponding service data to the user in the network at the receiver side in the form of multicast.

0076The MG transmits the multicast address and/or the service data corresponding to source information of the transmitted data to the user in the network at the receiver side in the form of multicast.

0077<figref idref="f0004">Figure 8</figref> shows the process of transmitting multicast data based on the H.248 protocol (the command request and the response mechanism of the H.248 protocol are omitted in <figref idref="f0002">Figure 3</figref>). The process includes the following steps: <ul id="ul0013" list-style="none" compact="compact"><li>Message 1: The MGC sends a "multicast transmit" message to the MG, where the message carries the information such as the multicast address and the source of the transmitted data. This message may be carried in the Add command to the terminal when the MG creates a terminal, or sent to an existing terminal through a Modify command.</li><li>Message 2: The MG allocates the address and port for sending service streams, and reports them to the MGC through the corresponding Reply message.</li><li>This message is mandatory when the MGC requires the information about the multicast source address. If the IGMP version supported by the user side is lower than 3 or the user does not need to filter the multicast source, it is optional as regards whether the address information allocated by the MG is reported to the MGC or not.</li><li>Message 3: The MG transmits multicast data to the specified multicast address.</li></ul>

0078An embodiment of the present invention provides a system for an MG to transmit multicast data, and provides specific devices in such a system. As shown in <figref idref="f0005">Figure 9</figref>, the system includes: an interconnected MGC (namely, the MGC corresponding to the system for an MG to transmit multicast data herein), and an MG (namely, the MG corresponding to the system for an MG to transmit multicast data herein). The MG includes a transmitting unit.

0079The transmitting unit is adapted to transmit the specified data to the user in the form of multicast according to the indication of the MGC.

0080The MGC includes a sending unit.

0081The sending unit is adapted to send an indication to the MG, indicating transmitting of data in the form of multicast. The indication carries: a multicast address, and/or source information of the multicast data.

0082Through the following instance, the method for an MG to receive multicast data and the method for an MG to transmit multicast data in an embodiment of the present invention are described together.

0083<figref idref="f0005">Figure 10</figref> illustrates the application scenario of the present invention. The multicast source and the multicast user are in two different IP networks, and the two networks are interconnected through an MG. In the prior art, the multicast data sent by the multicast source in network 2 is unable to pass through the gateway. Therefore, the users in network 1 are also unable to receive the multicast data from the multicast source. This problem is solved by extending the H.248 in an embodiment of the present invention. After receiving an indication from the MGC, the MG sends an IGMP message to the adjacent router in network 2, and reports its multicast group membership, thus joining a multicast group in order to receive multicast data from the specified multicast source. Meanwhile, at the network 1 side, the MG acts as a multicast transmitting source to transmit the multicast data received at the network 2 side in the form of multicast. In this case, the user in network 1 may use the prior art to join the multicast group to which the MG transmits the multicast data, receive the multicast data, thus forwarding the multicast media and signaling. Likewise, this embodiment of the present invention is also suitable for the scenario with multiple networks interconnected through an MG. That is, each MG acts as a multicast user at the multicast source side for receiving multicast data; and acts as a multicast transmitting source at the other side (multicast user side) of the network, and transmits the received data out in the form of multicast.

0084As shown in <figref idref="f0006">Figure 11</figref>, based on the application scenario shown in <figref idref="f0005">Figure 10</figref>, Router 1 and Router 2 are distributed on two different IP networks, and the two networks are interconnected through an MG. <figref idref="f0006">Figure 11</figref> supposes that the multicast transmitting source is located in the network at the Router 2 side. It should be noted that <figref idref="f0006">Figure 11</figref> shows only the process between entities correlated to the MG. For brevity, <figref idref="f0006">Figure 11</figref> omits the operations and processes outside the two routers (including the process from the multicast source to Router 2 and the process between Router 1 and the multicast user of the network).

0085The process for an MG to forward multicast media and signaling includes the following steps: <ul id="ul0014" list-style="none" compact="compact"><li>Message 1: The MGC sends an Add command to the MG to create a terminal, in order to join a multicast group and receive multicast data. The Add command carries the relevant "Multicast Group Membership" information. Therefore, the MG may send an IGMP joining message to the adjacent router according to such information.</li><li>For an existing terminal, the relevant information may also be sent through the Modify command.</li><li>Message 2: The MG responds with a Reply message.</li><li>Message 3: According to the relevant multicast information received from the MGC, the MG sends an IGMP multicast membership message to the adjacent router, and joins a multicast group.</li><li>In this way, the MG may receive the multicast service data from the multicast group joined by the MG. The MG may also use the existing access control mechanism to receive only the data packets from the specified multicast source addresses and ports.</li><li>Message 4: The MGC instructs the MG to act as a multicast transmitting source to transmit the received multicast data to the user in another IP network in the form of multicast. The MGC sends a Modify command to the MG, where the command carries the information about the multicast transmitting, including the multicast address.</li><li>The MG may also act as a separate multicast transmitting source to transmit the data information of the specified address out. Besides, if the relevant information is not sent to the MG in the form of packages, the existing SDP parameters may be used instead to set the Remote address to a type-D multicast address, and the multicast data is transmitted to such a multicast address.</li><li>Message 5: The MG allocates the address and port for sending service streams, and reports them to the MGC through the corresponding Reply message.</li><li>Message 6: The MG transmits multicast services to the network.</li></ul>

0086Supplementary notes: <ol id="ol0008" compact="compact"><li>(1) The IGMP protocol is applicable to the IPv4 system. For an IPv6 system, the MLD protocol applies. The IPv6-based host uses an MLD message to report its multicast members, and the IPv6-based router uses an MLD query message to collect the multicast user information. This embodiment of the invention also provides support of the IPv6 system, namely, supports the MLD message in the same way as described above. The difference is that the corresponding multicast address parameter is a multicast address of the IPv6 format, and the multicast membership report and the query message are an MLD message.</li><li>(2) In the foregoing solution, the MGC sends a signal about the multicast group membership to the MG, where the signal carries a user operation for subscription information of a specific multicast address. In the IGMP, a report message may carry more than one record, and each record includes a user operation for subscription information of a specific multicast address. Therefore, in the solution provided above, if multiple operations for the user subscription relation need to be provided, the operation is performed through multiple report messages. Nevertheless, the parameters in the "Multicast Group Membership" signal may be modified so that one message carries report information of one or more multicast address membership records. First, a parameter needs to be added, for example, a parameter named "Number of Group Records", to indicate the number of multicast address membership records carried in the signal. That is, each record is an entry of report information for a specific multicast address. The subsequent modification comes in two modes: <ol id="ol0009" compact="compact"><li>(i) The type of the relevant parameters in the signal is modified, and the single-parameter form is modified to the one-dimension vector form. For example, the "Multicast Address" parameter is defined as the form of a one-dimension vector, and carries N multicast addresses (N is equal to the number of group records); the "Record Type" parameter is defined as the form of a one-dimension vector, and carries N record types (N is equal to the number of group records), where the sequence of the record types correspond to the sequence of foregoing multicast addresses uniquely; the "Number of Sources" parameter is defined as the form of a one-dimension vector, and carries N source addresses (N is equal to the number of group records), where the sequence of source addresses corresponds to the sequence of the foregoing multicast addresses uniquely. Likewise, the "Source Address" parameter is defined as the form of a one-dimension vector, and carries N source address lists (N is equal to the number of group records), where the sequence of source address lists corresponds to the sequence of the foregoing multicast addresses uniquely, and each source address list is a one-dimension vector and carries N source addresses (N is equal to the number of source addresses). For example, the MGC needs to send these records to the MG: for the multicast address 224.65.10.150, new source addresses 202.113.0.180 and 202.113.0.181 are allowed, and old source addresses 201.0.0.100 and 201.0.0.101 are blocked; for the multicast address 224.65.0.100, it is changed to the inclusive mode to receive the multicast data from the source addresses 200.1.1.50, 200.1.1.51, and 200.1.1.52. According to the method provided above, the record information needs to be sent to the MG in three attempts; according to the modification made here, the record information is sent to the MG in only one attempt. The format is as follows: <ul id="ul0015" list-style="none" compact="compact"><li>The value of the "Number of Group Records" parameter is 3.</li><li>The "Multicast Address" parameter carries (224.65.10.150, 224.65.10.150, 224.65.0.100);</li><li>The "Record Type" parameter carries (ALLOW_NEW_SOURCES, BLOCK_OLD_SOURCES, CHANGE_TO_INCLUDE_MODE).</li><li>The "Number of Sources" parameter carries (2, 2, 3).</li><li>The "Source Address" parameter carries ((202.113.0.180, 202.113.0.181), (201.0.0.100, 201.0.0.101), (200.1.1.50, 200.1.1.51, 200.1.1.52)).</li><li>The foregoing example omits other parameters possibly carried in the signal.</li></ul></li><li>(ii) The parameters (1)-(4) in the existing signal are deleted, and a new parameter is defined in the signal. For example, the new parameter may be "Group Record" for defining report information of the user subscription relation. This parameter further carries several relevant parameters, including: Multicast Address, Record Type, Number of Sources, and Source Address. The meanings and types of such parameters are the same as the initial definition of this embodiment of the invention. The sequence of such parameters may be specified by the MGC, or the MGC indicates the sequence to the MG beforehand. The "Group Record" parameter may be defined as the form of a one-dimension vector, or the form of a list. Each signal carries N Group Records (N is equal to the number of group records). For example, the MGC needs to send these records to the MG: for the multicast address 224.65.10.150, new source addresses 202.113.0.180 and 202.113.0.181 are allowed, and old source addresses 201.0.0.100 and 201.0.0.101 are blocked; for the multicast address 224.65.0.100, it is changed to the inclusive mode to receive the multicast data from the source addresses 200.1.1.50, 200.1.1.51, and 200.1.1.52. According to the method provided above, the record information needs to be sent to the MG in only one attempt rather than three attempts. The format is as follows: <ul id="ul0016" list-style="none" compact="compact"><li>The value of the "Number of Group Records" parameter is 3.</li></ul> The "Group Record" parameter carries ((224.65.10.150, ALLOW_NEW_SOURCES, 2, (202.113.0.180, 202.113.0.181)), (224.65.10.150, BLOCK_OLD_SOURCES, 2, (201.0.0.100, 201.0.0.101)), (224.65.0.100, CHANGE_TO_INCLUDE_MODE, 3, (200.1.1.50, 200.1.1.51, 200.1.1.52))) if it is in the form of a one-dimension vector. </li></ol> The foregoing example omits other parameters possibly carried in the signal. </li><li>(3) The foregoing solution is about the scenario with only one multicast source. If there is more than one multicast source, the relevant support may also be provided. For example, if multiple multicast sources exist, the MGC may instruct the MG to create a context for each multicast source according to the method in this embodiment of the invention. Each context transmits the multicast data received from a specific multicast source in the form of multicast, thus supporting multiple multicast sources. In this case, only one context needs to be created, and the context includes multiple terminals. The multicast media and signaling are forwarded through the internal topology relation of the context. </li><li>(4) In this embodiment, the H.248 protocol is applied. Other media gateway control protocols such as MGCP are theoretically similar. This embodiment of the invention also supports other media gateway control protocols.</li><li>(5) In the method for forwarding multicast media and signaling provided above, the MG transmits the received multicast data out in the form of multicast. Here the MG may also join the multicast group as a multicast user, and receive the multicast data. At the other side, the MG may also forward the received data out in the form of unicast.</li><li>(6) In the foregoing example, the MGC sends the indication of the MG through the signals in the H.248. Here the indication of the MG may be sent in other modes based on the H.248, including but not limited to: the indication of the MG is sent through events; through attributes; or through extending the SDP.</li></ol>

0087The application scenarios of this embodiment of the invention include but are not limited to the following: <ol id="ol0010" compact="compact"><li>(1) According to the multicast membership information and the relevant indication received from the MGC, the MG sends an IGMP message to the adjacent router to join a multicast group. Therefore, as a multicast user, the MG may receive the multicast service from the relevant multicast group.</li><li>(2) The MG may transmit the received multicast service out in the form of multicast according to the information (such as multicast address) indicated by the MGC.</li><li>(3) For the received multicast service, the MG may forward the received data out in the form of unicast, which is already supported by the H.248 protocol.</li><li>(4) According to the indication information of the MGC, the MG may act as a multicast transmitting source to transmit the data of the specified address out in the form of multicast.</li></ol>

0088In the final analysis, a method for an MG to receive multicast data is provided in an embodiment of the present invention, where the MGC sends a multicast-related indication to the MG. Afterward, the MG reports multicast memberships to the router in the network at the multicast source side according to the indication of the MGC. Therefore, the MG joins or quits the multicast group as a user, and receives multicast data. The indication includes several contents extended in an embodiment of the invention in order to enable the MG to receive multicast data.

0089Accordingly, a system for an MG to receive multicast data is provided in an embodiment of the present invention.

0090Accordingly, an MG and an MGC are provided in an embodiment of the present invention.

0091A method for an MG to transmit multicast data is provided in an embodiment of the present invention, where the MGC sends a multicast-related indication to the MG. Afterward, the MG acts as a multicast source to transmit the corresponding service data to the users in the network at the receiver side in the form of multicast according to the indication of the MGC. The indication includes several contents extended in an embodiment of the invention in order to enable the MG to transmit multicast data.

0092Corresponding to the method for an MG to transmit multicast data, a system for an MG to transmit multicast data is provided in an embodiment of the present invention.

0093The foregoing two types of methods and systems may be combined to interconnect the multicast path between networks, thus meeting requirements of various applications more flexibly. Moreover, the MG device does not need to be updated in the embodiment of the invention.

0094Although the invention has been described through some exemplary embodiments, the invention is not limited to such embodiments. It is apparent that those skilled in the art can make various modifications and variations to the present invention without departing from the spirit and scope of the present invention. The present invention is intended to cover these modifications and variations provided that they fall in the scope of protection defined by the claims or their equivalents.