EP3632065B1 - Method of providing information to an audio/video receiver device and corresponding apparatus - Google Patents

Description

FIELD
• The present disclosure generally relates to the field of compatibility between protocol versions used by a router device and an audio/video receiver device configured to receive audio/video streams from the router device.
BACKGROUND
• Any background information described herein is intended to introduce the reader to various aspects of art, which may be related to the present embodiments that are described below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present disclosure. Accordingly, it should be understood that these statements are to be read in this light.
• The Internet Group Management Protocol (IGMP) is a communication protocol that is part of Internet Protocol (IP) multicast. IP multicast is a method of sending IP datagrams to a group of interested receivers in a single transmission. It is a form of point-to-multipoint communication often employed for streaming media applications such as online streaming video and gaming on the Internet and private networks. IGMP operates between an IP multicast receiver device and a local IP multicast router. To receive an IP multicast stream, the IP multicast receiver device requests membership to an IP multicast group for the IP multicast stream through its local IP multicast router while the local IP multicast router listens for these requests and periodically sends out subscription queries. There exist multiple versions of IGMP. IGMP version 2 (IGMPv2) improves over IGMP version 1 (IGMPv1) by adding the ability for an IP multicast receiver device to signal desire to leave a multicast group (IGMP 'leave'). IGMP version 3 (IGMPv3) improves over IGMPversion 2 mainly by supporting source-specific multicast (SSM). Source-specific multicast is a method of delivering IP multicast packets in which the only packets that are delivered to an IP multicast receiver device are those originating from a specific source address requested by the IP multicast receiver device. By so limiting the source, SSM reduces demands on the network and improves security.
• While currently sold IP multicast receiver devices comply with IGMPv3, there are still many IP multicast routers functioning in IGMPv2 mode. An IP multicast receiver device, e.g., an IP Set Top Box (IPSTB) for receiving digital television over IP or an IP digital television (IPDTV), starting up in IGMPv3 mode, will not be able to request and receive IP multicast streams from an IGMPv2 IP multicast router until it is aware that the IP multicast router is using IGMPv2. This considerably slows down the reception of a first IP multicast stream upon startup of the IGMPv3 IP multicast receiver device. Upgrading of the IGMPv2 IP multicast router to IGMPv3 is not always possible. Replacement is costly.
• There is thus a need for a solution to improve slow IP multicast receiver device startup due to incompatibility between IGMP versions of the IP multicast receiver device and an IP multicast router, that does not require an upgrade of the IP multicast router equipment to the latest IGMP version nor replacement of the equipment.
• The publication IGMP AND MLD SNOOPING SWITCHES; DRAFT-IETF-IDMR-SNOOP-01.TXT addresses the aim to reduce the join latency for hosts if a switch does not support IGMPv3 and suggests that in mixed deployment mode initially the Query Interval be set to a low value until the compatibility modes have stabilized both host and routers on the same IGMP version. After stabilization, the Query Interval could be increased to its original value.
• ThepublicationEP 1 983 713 A1 considers
  that ring reconfiguration after link failure is normally only
  completed after a IGMP general query message and discloses a snooping node that is connected to the IGMP Router to send the General Query on behalf of the IGMP Router after a change of
  topology to reduce network recovery time.
SUMMARY
• The invention is directed to
  a method in accordance withclaim 1 and a device in accordance with claim 9.
• The dependent claim cover further embodiments.
BRIEF DESCRIPTION OF THE DRAWINGS
• More advantages of the present disclosure will appear through the description of particular, non-restricting embodiments. In order to describe the manner in which the advantages of the present disclosure can be obtained, particular descriptions of the present principles are rendered by reference to specific embodiments thereof which are illustrated in the appended drawings.
• The embodiments described can be combined to form particular advantageous embodiments. In the following figures, items with same reference numbers as items already described in a previous figure will not be described again to avoid unnecessary obscuring the disclosure. The embodiments will be described with reference to the following drawings in which:
• Figure 1 is a message header of an example message for requesting if devices are interested in receipt of a multicast audio/video stream.
• Figure 2 is asystem 2 for transmission and reception of audio/video streams.
• Figure 3 is a flow chart of data communication messages exchanged between the devices of thesystem 2 offigure 2.
• Figure 4 is an embodiment of a system 4 per the principles of the present disclosure.
• Figure 5 is a flow chart of data communication messages exchanged between the devices of system 4 depicted infigure 4.
• Figure 6 is an embodiment ofsystem 6 per the principles of the present disclosure.
• Figure 7 is providing information to an audio/video stream receiver device per the present principles.
• Figure 8 is an embodiment of a device 8 for implementing the method of per the principles of the present disclosure.
• It should be understood that the drawings are for purposes of illustrating the concepts of the disclosure and are not necessarily the only possible configuration for illustrating the disclosure.
DETAILED DESCRIPTION
• The present description illustrates the principles of the present disclosure.
• All examples and conditional language recited herein are intended for educational purposes to aid the reader in understanding the principles of the disclosure and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions.
• As discussed in the background section, an IP multicast receiver device, starting up in IGMPv3 mode, will not be able to request reception of IP multicast streams from an IGMPv2 IP multicast router until it is aware that the IP multicast router is using IGMPv2 and it can revert to IGMPv2. This considerably slows down the reception of a first IP multicast stream upon startup of the IGMPv3 IP multicast receiver device. This is because any IGMPv3 IGMP join requests from the IGMPv3 IP multicast receiver device will be discarded by the IGMPv2 IP multicast router. IGMPv3 comprises a backwards compatibility feature which specifies that if an IP multicast receiver device receives an IGMPv1 or IGMPv2 General Query message, the IP multicast receiver device is required to revert to the older, IGMPv1 or IGMPv2 mode of operation. IGMP General Query messages are transmitted by an IP multicast router every 125 seconds. It may thus take up to more than 125 seconds from startup of an IGMPv3 IP multicast receiver device to set up reception of a first IP multicast stream from an IGMPv2 IP multicast router.
• Figure 1 is a message header of an example message for requesting if devices are interested in receipt of a multicast audio/video stream. In particular is depicted infigure 1 an IGMP message header of an IGMP Membership Query Message. To be compatible with older version routers, the IGMPv3 specification requires that an IGMPv3 host operates in v1 and v2 compatibility modes. IGMPv3 hosts must keep state per local interface regarding the compatibility mode of each attached network. A host's compatibility mode is determined from the Host Compatibility Mode (HCM) variable which can be in one of three states: IGMPv1, IGMPv2 or IGMPv3. This variable is kept per interface and is notably dependent on the version of General Queries heard on that interface. There are three types of Membership Query Messages. A Membership Query Message has a Type field set to 0x11. The previously discussed General Query message is one of the possible Membership Query Messages. An IGMP General Query is a Membership Query Message of which both the Group Address field and the Number of Sources (N) field are zero. The IGMP version of a General Query Message can be determined as follows:
• IGMPv1: length 8 octets and Max Resp Code field is zero.
• IGMPv2: length 8 octets and Max Resp Code field is non-zero.
• IGMPv3: length >= 12 octets.
• Figure 2 is asystem2 for transmission and reception of audio/video streams. In particular,system2 is suitable for transmission and reception of IP multicast streams including transmission and reception of audiovisual data such as audio/video streams.System2 includes adigital television DTV14, a SetTop Box STB13, aHome Network Gateway12, a Broadband RemoteAccess Server BRAS11 and aProvider Network10.DTV14 is connected toSTB13 via a High Definition Multimedia Interface (HDMI).STB13 is connected to HNG12 via an Ethernet link in what is commonly referred to as a Local Area Network (LAN).HNG12 is connected toBRAS11 via a Digital Subscriber Link (DSL) or a Data Over Cable Service Interface Specification (DOCSIS) or a Passive Optical Network (PON) and via subsequent network equipment not shown.BRAS11 is connected toProvider Network10 via a high bandwidth communication link.BRAS11 includes a DHCP server and an IGMPv2 IP multicast router, whileSTB13 is an IGMPv3 IP multicast receiver.HNG12 is functioning in bridge mode (Open Systems Interconnection model (OSI) layer 2) for DHCP and IGMP traffic. That is,HNG12 is not taking an active part in DHCP and IGMP communication betweenSTB13 andBRAS11;STB13 can subscribe to reception of an IP multicast stream transmitted byBRAS11 through transmission of an IGMP join message. IfBRAS11 receives such a message, it can transmit the requested IP multicast stream toSTB13.STB13 then decodes the information included in the received IP multicast stream and transmits the decodedstream DTV14, which renders the audiovisual information included in the multicast stream as moving images and sound.
• Figure 3 is a flow chart of data communication messages exchanged between the devices ofsystem2 as depicted infigure 2. From left to right are shown, audio/video streamreceiver device STB13, intermediate device HNG12, andBRAS11 including arouter112. As aforementioned,HNG12 functions in bridge mode and does therefore not take active part in the communication betweenSTB13 andBRAS11, apart from doing NAT.STB13 uses a first protocol version to subscribe to a transmission by the audio/video stream router device of an audio/video stream (e.g., IGMPv3 mode), while the IP multicast router inBRAS11 uses a second protocol version (e.g., n IGMPv2). The flow chart starts with the IGMPv2IP multicast router112 inBRAS11 transmitting anIGMPv2 General Query300. As aforementioned, such messages are transmitted every 125s. As it happens, the IGMPv2 General Query message is transmitted toSTB13 while it is switched off. The message is therefore not received bySTB13. WhenSTB13 boots (starts up)305,STB13 is functioning in IGMPv3 mode. At startup,STB13 requests an IP address from the DHCP server inBRAS11. This results some exchanges betweenSTB13 andBRAS11 according to the DHCP protocol(310-325). STB is finally attributed an IP address. Then,STB13 wishes to subscribe to an IP multicast stream and therefore sends330 an IGMPv3 join message toBRAS11. However, since the IP multicast router inBRAS11 is functioning in IGMPv2 mode, the IGMPv3 join message is discarded.STB13 repeatedly(335, 340) sends IGMPv3 join messages toBRAS11 in the hope of a reply. These messages are discarded byBRAS11. One hundred twenty-five seconds after having sent IGMPv2General Query message300,BRAS11 repeats345 the transmission of the IGMPv2 General Query message. This time, the message is received bySTB13, andSTB13 switches to IGMPv2 mode of operation. Following this, it repeats the transmission of the IGMP join message, but this time in IGMPv2 format. This time, the message is considered by the IP multicast router inBRAS11, and the requested IP multicast stream is transmitted360 toSTB13. The stream is received and decoded bySTB13, which outputs365 audiovisual data on its HDMI interface, and the audiovisual data is rendered byDTV14. It can thus be observed that 125 seconds are lost, spent in waiting for the next transmission of the IGMP General Query message. During this waiting time (startup time, startup- or boot-delay), no audiovisual stream is received bySTB13, and no audiovisual data is rendered byDTV14. The above is a worst-case scenario. In practice, because there is no synchronization between the transmittal byBRAS11 of General Query messages and startup ofSTB13, the General Query message may be received after startup ofSTB13, in whichcase STB13 will be able to switch to IGMPv2 earlier, resulting in a delay that is shorter than 125 seconds. In general, it can thus be said that a random wait time of maximum 125 seconds before being able to show a picture onDTV14 can be expected with thepriorart system2 offigure 2.
• Figure 4 is an embodiment of a system4 per the principles of the present disclosure.HNG12 includes aproxy device121, of which the functioning is explained with the aid offigure 5.HNG12 may include local memory for storing code and for storing data, one or more processors for executing the code and for reading and writing data to the local memory.HNG12 may further include wired or wireless network interfaces, e.g. one wired network interface for connecting to via external network toBRAS11 and two network interfaces e.g., wired Ethernet and wireless WiFi for connecting to a local network that includesSTB13. An example hardware for a HNG according to the present principles is depicted infigure 8.
• Figure 5 is a flow chart of example data communication messages exchanged between the devices of system4 as depicted infigure 4. From left to right are shown:STB13,proxy121 inHNG12, andBRAS11. As aforementioned,HNG12 functions in bridge mode and does therefore not take active part in the communication betweenSTB13 andBRAS11, apart from doing NAT.HNG12 is an intermediate device between the external (Wide Area Network, WAN) network and the local network (LAN). Per the principles of the present disclosure, the intermediate device (e.g.,HNG12 by means of proxy121), snoops (listens, monitors, receives) the data communication between an audio/video stream router device (e.g., BRAS11) in the WAN and an audio/video stream receiver device (e.g., STB13) in the LAN. For example, intermediate device HNG12 listens to DHCP and IGMP packets exchanged between the WAN and the LAN and obtains a protocol version to use for the audio/video stream receiver device to subscribe to a transmission by the audio/video stream receiver device of an audio/video stream. For example,STB13 in the LAN is functioning in IGMPv3 mode of operation, while the IP multicast router device in theWAN BRAS11 is functioning in IGMPv2 mode of operation. The flow chart begins with the IGMPv2IP multicast router112 inBRAS11 transmitting anIGMPv2 General Query300. As aforementioned,such messages300 are transmitted every 125s. As it happens, the IGMPv2General Query message300 is transmitted toSTB13 while it is switched off. The message is therefore not received bySTB13. However, and per the principles of the present disclosure, the proxy's IGMP snooper function receives the IGMP General Query toSTB13 and obtains (reads) information relating to the IGMP operating version (protocol version) of theIP multicast router112 inBRAS11 frommessage300. WhenSTB13 boots (starts up)305,STB13 thus functions in IGMPv3 mode. At startup,STB13 requests an IP address from theDHCP server111 inBRAS11, e.g., a DHCP Discover message, which is an example of a message indicative of the audio/video stream receiver device starting up. This results some exchanges betweenSTB13 andBRAS11 according to the DHCP protocol(310-325).STB13 is finally attributed an IP address. Per the principles of the present disclosure and as aforementioned, intermediate device HNG12 by means ofproxy 121 snoops the DHCP exchanges between theDHCP server111 inBRAS11 andSTB13;HNG12 by means ofproxy121 thus receives the DHCP messages transmitted bySTB13 toDHCP server111 and is thus aware of the fact thatSTB13 is in a booting process (is starting up, is in a startup process); it therefore detects510 thatSTB13 is booting or has booted. Accordingly, and based on the obtained information relating to the IGMP operating version of the IP multicast router112 (protocol version) inBRAS11, it transmits (injects) a message indicative of the audio/video stream router device (BRAS11) using a protocol version that does not support source-specific multicast into the LAN, e.g., an IGMPv2General Query message515.STB13 receives this message and switches350 to IGMPv2 mode of operation. Then,STB13 wishes to subscribe to an IP multicast stream and therefore sends355 an IGMPv2 join message to the IP multicast router inBRAS11. Since the IP multicast router inBRAS11 is also functioning in IGMPv2 mode, the IGMPv2 join message is not discarded. The message is considered by the IP multicast router inBRAS11, and the requested IP multicast stream is transmitted360 toSTB13. The stream is received and decoded bySTB13, which outputs365 audiovisual data on its HDMI interface, and the audiovisual data is rendered byDTV14. In the above described embodiment the protocol version to use for the audio/video stream receiver device to subscribe to a transmission by the audio/video stream router device of an audio/video stream, e.g., the IGMP version of the audio/video stream router device, is obtained by 'snooping' (listening, monitoring, receiving in a non-intrusive manner) the IGMP General Query Messages coming from the IP multicast router. For example, if the length of a received IGMP General Query message is 8 octets, the IGMP version used by the IP multicast router device is IGMPv1 or IGMPv2; in other words, the audio/video stream router device (the IP multicast router device) does not support SSM. If the length is twelve octets or more, it is an IGMPv3 General Query message; in other words, the IP multicast router device supports SSM. A protocol version to use for the audio/video stream receiver device to subscribe to a transmission by the audio/video stream router device of an audio/video stream, e.g., an Internet Group Management Protocol version of said received Internet Group Management Protocol General Query message, can thus be obtained from a length of a received Internet Group Management Protocol General Query message.
• According to a different embodiment, the protocol version to use for the audio/video stream receiver device to subscribe to a transmission by the audio/video stream router device of an audio/video stream, e.g., the IGMP version of the IP multicast router device, can be obtained from reading out the previously mentioned Host Compatibility Mode (HCM) variable (parameter) of the interface of the IP multicast receiver device receiving the IGMP General Query messages from the IP multicast router. This variable (parameter) is refreshed upon receipt of IGMP General Query messages.
• It can thus be observed that through the principles of the present disclosure no time is lost, no time is spent in waiting for the next transmission of the IGMP General Query message. Startup time ofSTB13 is thus considerably reduced with the system4 offigure 4, to a normal startup time required for bootingSTB13, as the first connection to a multicast stream ofSTB13 is not delayed due to an incompatibility issue between the router and the STB.
• Figure 6 is asystem6 per the principles of the present disclosure.HNG62 is different fromHNG12 in thatHNG62 is not functioning inOSI layer 2 bridge mode and includes aDHCP server621 and an IGMPv2IP multicast router622. The principles of the present disclosure equally apply in such configuration. Therefore,proxy121 inHNG62 offigure 6 is no different thanproxy121 inHNG12 offigure 4, a part from that DHCP and IGMP packets are not exchanged betweenBRAS11 andSTB13 but betweenHNG62 andSTB13. Still different embodiments than depicted infigures 4 and6 are possible and do not modify the present principles. For example, a BRAS may include an IGMP router while a HNG includes a DHCP server, or vice versa. Since the proxy is in the HNG that, as an intermediate device, has a central position, the proxy can snoop the data communication, e.g. DHCP and possibly IGMP packets according to the embodiment chosen, can receive from the audio/video stream router device a message (e.g., an IGMP General Query message), can obtain from this message a protocol version (e.g., IGMPv2) to use for the audio/video stream receiver device to subscribe to a transmission by the audio/video stream router device of an audio/video stream, and when the proxy receives a message indicative of the audio/video stream receiver device starting up (e.g., a DCHP Discover message), can intervene by transmitting a message indicative of the audio/video stream router device using a protocol version not supporting source-specific multicast (e.g. an IGMPv3 General Query message), to the audio/video stream receiver device (the IP multicast receiver device) per the principles of the present disclosure when required no matter where the DHCP server and IGMP router are placed.
• According to an embodiment of the principles of the present disclosure, the LAN including more than the one STB device, the proxy/HNG, when receiving a message indicative of the audio/video receiver device starting up (a DHCP communication between a LAN device and a DHCP server), subordinates the discussed transmission of the message indicative of the audio/video stream router device using a protocol version not supporting source-specific multicast (e.g., an IGMPv2 General Query) to the LAN device to a verification (checking) whether the audio/video stream receiver device from which the message indicative of the audio/video receiver device starting up is received corresponds to a device for which the transmitting of the message indicative of said audio/video stream router device using a protocol version not supporting source-specific multicast is enabled. This allows the intermediate device (e.g. the proxy/HNG) to be configured to enable or disable the transmission (injection) of the message indicative of the audio/video stream router device using a protocol version not supporting source-specific multicast (e.g., the IGMPv2 General Query message) for some or all LAN devices. Such verification (checking) can for example be done based on the DHCP option 60 field in a received DHCP Discover message. Option 60 (Vendor Class Identifier (VCI)) in the DHCP Discover message is widely used to represent device type or user class of the DHCP client. It is a variable-length string of characters. Such configuration for enabling/disabling the transmission of the message indicative of the audio/video stream router device using a protocol version not supporting source-specific multicast may be done by a network administrator and may be stored in a memory of the intermediate device. The conditions for transmission by the intermediate device of the message indicative of said audio/video stream router device using a protocol version not supporting source-specific multicast to the LAN device then are that the protocol version to use for the audio/video stream receiver device to subscribe to a transmission by the audio/video stream router device of an audio/video stream is a version not supporting SSM AND that LAN device corresponds to a device of which the DHCP Discovery option 60 value is memorized in the intermediate device for which such transmission is allowed (enabled). In all other cases, the transmission is not done.
• According to a different embodiment, the intermediate device's subordination of transmission of message indicative of the audio/video stream router device using a protocol version not supporting source-specific multicast to the LAN device to a verification whether the audio/video stream receiver device from which the message indicative of the audio/video receiver device starting up is received corresponds to a device for which the transmitting of the message indicative of the audio/video stream router device using a protocol version not supporting source-specific multicast is enabled is rather based on the Media Access Control (MAC) address, which, contrary to the IP address of a device or network interface of a device, does not change. The conditions for transmission of the message indicative of the audio/video stream router device using a protocol version not supporting source-specific multicast to the LAN device then are that the protocol version to use for the audio/video stream receiver device to subscribe to a transmission by the audio/video stream router device of an audio/video stream is a protocol version not supporting source-specific multicast AND the value of the MAC address of the LAN device corresponds to the MAC address of a LAN device which is memorized in the intermediate device for being that of a LAN device to which such transmission is allowed (enabled). Otherwise, the transmission is not done.
• At least one advantage of the above mentioned embodiments of subordination to selectively enable transmission (injection) of transmission of message indicative of the audio/video stream router device using a protocol version not supporting source-specific multicast for specific LAN devices is that it limits the message traffic on the LAN and avoids creating unwanted side effects for devices that are not concerned.
• According to an embodiment that can be combined with the previous embodiments, the transmission of a message indicative of the audio/video stream router device using a protocol version not supporting source-specific multicast for specific LAN devices is further subordinated to checking whether an acknowledge message (e.g., a DHCP ack following a DHCP Discover) has been received that is destined to the LAN device. At least one advantage of this embodiment is that it is thus ensured that the LAN device is ready to receive and consider the message indicative of the audio/video stream router device using a protocol version not supporting source-specific multicast when transmitted to it by the intermediate device, because the receipt of the DHCP ack indicates that the IP address of the LAN device is confirmed by the DHCP server. The conditions for transmission of the message indicative of the audio/video stream router device using a protocol version not supporting source-specific multicast by the intermediate device to the LAN device then are that the protocol version to use for the audio/video stream receiver device to subscribe to a transmission by the audio/video stream router device of an audio/video stream is a protocol version not supporting source-specific multicast AND that an acknowledge message (e.g., DHCP ack following a DHCP Discover) destined to the LAN device has been received (snooped) by the intermediate device. Otherwise, the transmission is not done.
• Figure 7 is a flow chart of an embodiment of a method of providing information to an audio/video stream receiver device per the principles of the present disclosure. Themethod700 is for example implemented by an intermediate device such asHNG12 or61 interconnecting an audio/video stream router device such asIGMP router112 or622 and an audio/video stream receiver device such asSTB13. The method includes receiving, from the audio/video stream router device, a first message(701-Yes) and obtaining702 from the first message a protocol version to use for the audio/video stream receiver device to subscribe to a transmission by the audio/video stream router device of an audio/video stream. The method further includes receiving, from the audio/video receiver device, a second message indicative of the audio/video receiver device starting up(703-Yes) and if the protocol version is a protocol version not supporting source-specific multicast(704-Yes), transmitting705, to the audio/video stream receiver device, a third message indicative of the audio/video stream router device using a protocol version not supporting source-specific multicast.
• Figure 8 is an embodiment of an intermediate device8 with processor and memory for implementing the method per the principles of the present disclosure. Device8 is forexample HNG12 offigure 4 orHNG62 offigure 6. It includes a central processing unit or processor800, amemory801, afirst network interface802, asecond network interface803, interconnected via aninternal communication bus810. Thefirst network interface802 is for example for a WAN connection including toBRAS11 offigure 4 orBRAS61 offigure 6. Thesecond network interface803 is for example for LAN connection including toSTB13. The functions as depicted inflow chart700 offigure 7 are performed in device8. For example, the first message in step701 is received byfirst network interface802 and step702 is performed by processor800. For example, the second message is received bysecond network interface803 and processor800 performsstep704. Finally, the message instep705 is transmitted by thesecond network interface803.
• It is to be appreciated that some elements in the drawings may not be used or be necessary in all embodiments. Some operations may be executed in parallel. Embodiments other than those illustrated and/or described are possible. For example, a device implementing the present principles may include a mix of hard- and software.
• It is to be appreciated that aspects of the principles of the present disclosure can be embodied as a system, method or computer readable medium. Accordingly, aspects of the principles of the present disclosure can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code and so forth), or an embodiment combining hardware and software aspects that can all generally be defined to herein as a "circuit", "module" or "system". Furthermore, aspects of the principles of the present disclosure can take the form of a computer readable storage medium. Any combination of one or more computer readable storage medium(s) can be utilized.
• Thus, for example, it is to be appreciated that the diagrams presented herein represent conceptual views of illustrative system components and/or circuitry embodying the principles of the present disclosure. Similarly, it is to be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable storage media and so executed by a computer or processor, whether such computer or processor is explicitly shown.
• A computer readable storage medium can take the form of a computer readable program product embodied in one or more computer readable medium(s) and having computer readable program code embodied thereon that is executable by a computer. A computer readable storage medium as used herein is considered a non-transitory storage medium given the inherent capability to store the information therein as well as the inherent capability to provide retrieval of the information there from. A computer readable storage medium can be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. Some or all aspects of the storage medium may be remotely located (e.g., in the 'cloud'). It is to be appreciated that the following, while providing more specific examples of computer readable storage mediums to which the present principles can be applied, is merely an illustrative and not exhaustive listing, as is readily appreciated by one of ordinary skill in the art: a hard disk, a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Claims (16)

1. A method (700) of providing information to an audio/video stream receiver device,characterized in that said method is implemented by an intermediate device interconnecting a router device and said audio/video stream receiver device, said method comprising:

   receiving (701), by snooping Internet Group Management Protocol, IGMP, messages transmitted by said router device, an IGMP General Query message and obtaining (702) from said IGMP General Query message a protocol version to use for said audio/video stream receiver device to subscribe to a transmission by said router device of an audio/video stream; and

   receiving (703), by snooping Dynamic Host Configuration Protocol, DHCP, messages transmitted by said audio/video stream receiver device, a DHCP message indicative of said audio/video stream receiver device starting up and if said protocol version is a protocol version not supporting Source-Specific Multicast, SSM, transmitting (705), to said audio/video stream receiver device, an IGMPv2 General Query message indicative of said router device using a protocol version not supporting SSM.
2. The method according to claim 1, wherein said audio/video stream is an Internet Protocol multicast audio/video stream.
3. The method according to claim 1 or 2, wherein said DHCP message is a DHCP Discover message.
4. The method according to claim 2 or 3, further comprising obtaining said protocol version of said IGMP General Query message from a length of said IGMP General Query message.
5. The method according to claim 2 or 3, further comprising obtaining said protocol version of said IGMP General Query message from a Host Compatibility Mode variable of said router device.
6. The method according to any of claims 1 to 5, further comprising applying an additional condition to said transmitting of said IGMPv2 General Query message to said audio/video stream receiver device of checking from said DHCP message if said audio/video stream receiver device from which said DHCP message is received corresponds to a device for which said transmitting of said IGMPv2 General Query message is enabled.
7. The method according to any of claims 1 to 5, further comprising applying an additional condition to said transmitting of said IGMPv2 General Query message to said audio/video stream receiver device of checking from said DHCP message if a Media Access Control, MAC, address of said audio/video stream receiver device corresponds to a device for which said transmitting of said IGMPv2 General Query message is enabled.
8. The method according any of claims 3 to 5, further comprising an additional condition to said transmitting of said IGMPv2 General Query message to said audio/video stream receiver device of checking whether a DHCP acknowledge message has been received that is destined to said audio/video stream receiver device.
9. A device (8) for providing information to an audio/video stream receiver device, comprising processor (800) and a memory (801) configured to:

   receive, by snooping Internet Group Management Protocol, IGMP, messages transmitted by a router device, an IGMP General Query message and obtain from said IGMP General Query message a protocol version to use for said audio/video stream receiver device to subscribe to a transmission by said router device of an audio/video stream;

   receive, by snooping Dynamic Host Configuration Protocol, DHCP, messages transmitted by said audio/video stream receiver device, a DHCP message indicative of said audio/video stream receiver device starting up and if said protocol version is a protocol version not supporting Source-Specific Multicast, SSM, to transmit, to said audio/video stream receiver device, an IGMPv2 General Query message indicative of said router device using a protocol version not supporting SSM.
10. The device according to claim 9, wherein said audio/video stream is an Internet Protocol multicast audio/video stream.
11. The device according to claim 9 or 10, wherein said DHCP message is a DHCP Discover message.
12. The device according to claim 10 or 11, wherein said processor and said memory are further configured to obtain said protocol version of said IGMP General Query message from a length of said IGMP General Query message.
13. The device according to claim 10 or 11, wherein said processor and said memory are further configured to obtain said protocol version of said IGMP General Query message from a Host Compatibility Mode variable of said router device.
14. The device according to any of claims 9 to 13, wherein said processor and said memory are further configured to apply an additional condition to said transmitting of said IGMPv2 General Query message to said audio/video stream receiver device of checking from said DHCP message if said audio/video stream receiver device from which said DHCP message is received corresponds to a device for which said transmitting of said IGMPv2 General Query message is enabled.
15. The device according to any of claims 9 to 13, wherein said processor and said memory are further configured to apply an additional condition to transmitting of said IGMPv2 General Query message to said audio/video stream receiver device of checking from said DHCP message if a Media Access Control, MAC, address of said audio/video stream receiver device corresponds to a device for which said transmitting of said IGMPv2 General Query message is enabled.
16. The device according any of claims 11 to 13, wherein said processor and said memory are further configured to apply an additional condition to said transmitting of said IGMPv2 General Query message to said audio/video stream receiver device of checking whether a DHCP acknowledge message has been received that is destined to said audio/video stream receiver device.

Images