Abstract:
A method and system for delivering content is provided. In one example, responsive to a request by a client device identifying a video program, the system is configured to determine different first and second network paths for delivery of the video program from a content source; deliver the video program via the first network path to the client device; and responsive to a change in status of the video program being delivered via the first network path, deliver the video program via the second network path to the client device.

Description:
CROSS-REFERENCE TO RELATED APPLICATION(S) 
       [0001]    The present application is a continuation application of U.S. patent application Ser. No. 12/614,058 filed Nov. 6, 2009. The content of the foregoing application is incorporated by reference in its entirety. 
     
    
     BACKGROUND 
       [0002]    Digital channels can be broadcast to subscribers via a network. The network may communicate the digital channels to node groups, which correspond to a group of subscribers located near one another (e.g., within a neighborhood). In some instances, only a portion of the channels are being simultaneously watched by the subscribers of a single node group, resulting in bandwidth being used to transport unwatched channels. 
       SUMMARY 
       [0003]    The following presents a simplified summary in order to provide a basic understanding of some aspects as described herein. The summary is not an extensive overview of all aspects. It is neither intended to identify key or critical elements nor to delineate the scope of the present disclosure. The following summary merely presents various example concepts in a simplified form as a prelude to the more detailed description below. 
         [0004]    According to some aspects, systems and methods may include, responsive to a request by a client device identifying a video program, determining different first and second network paths for delivery of the video program from a content source; delivering the video program via the first network path to the client device; and responsive to a change in status of the video program being delivered via the first network path, delivering the video program via the second network path to the client device. 
         [0005]    According to some aspects, systems and methods may include, responsive to a request by a client device identifying a video program, determining different first and second network paths for delivery of the video program from first and second content sources; delivering the video program via the first network path from the first content source to the client device; and responsive to a change in status of the video program being delivered via the first network path, delivering the video program via the second network path from the second content source to the client device. 
         [0006]    According to some aspects, systems and methods may include, responsive to a request by a client device identifying a video program, determining a redundant join type based on at least one of the following: whether multiple sources are available that provide the video program, a present balance of traffic on one or more video interface inputs of an edge device, or a subscriber service level; and generating and communicating a program setup request comprising the redundant join type to the edge device. 
         [0007]    These and other aspects of the disclosure will be apparent upon consideration of the following detailed description. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0008]    A more complete understanding of the present disclosure and the potential advantages of various aspects described herein may be acquired by referring to the following description in consideration of the accompanying drawings, in which like reference numbers indicate like features, and wherein: 
           [0009]      FIG. 1  is a functional block diagram of an illustrative system for providing redundant multicast service to one or more client devices; 
           [0010]      FIG. 2  is a functional block diagram of an illustrative computer, which may embody any of the functional blocks of  FIG. 1 ; 
           [0011]      FIGS. 3A-D  are signaling diagrams showing illustrative interactions between functional blocks of  FIG. 1 ; and 
           [0012]      FIG. 4  is a flow chart showing illustrative steps that may be performed by the system of  FIG. 1 . 
       
    
    
     DETAILED DESCRIPTION 
       [0013]      FIG. 1  is a functional block diagram of an illustrative system for providing redundant multicast service to one or more client devices. In this example, the system includes one or more content sources  104  (e.g., sources A, B, and C), a network  101 , and one or more client devices  110  (e.g., client devices  110 A-D). The system as shown also includes a head end  150 , which may include, for example, an edge resource manager (ERM)  102  or other type of edge device controller, routers  106 A and  106 B, one or more edge devices such as quadrature amplitude modulation devices (QAMs)  108 A and  108 B, and a switched digital video session manager (SDVSM)  103 . The system may also include other head ends similar to or different from head end  150 , each serving other client devices. The interconnections between the various functional blocks in  FIG. 1  may be unidirectional or bidirectional as desired. 
         [0014]    The system may act to provide content (e.g., video and/or audio content) from one or more of sources  104  to one or more of client devices  110 . In some embodiments, the system may be a television content distribution system or an Internet Protocol television (IPTV) distribution system. Accordingly, the content may include television shows, movies, advertisements, etc. The content may be delivered to client devices  110  via switched video techniques, which is also known as switched digital video (SDV). 
         [0015]    In a typical television or IPTV distribution system, content is provided over a plurality of different channels. Using SDV, the physical distribution path between head end  150  and one or more of client devices  110  carries only a subset of available channels based on channel requests by those client devices. For instance, only those channels requested by the client devices at any given time may be carried on the distribution path. While those channels not requested may still be available by the system, those non-requested channels may not be propagated into the distribution path. Because only a subset of the channels are typically requested at any given time, and because only a subset of the client devices will be in use at any given time, SDV may allow more available channels to be provided without necessarily increasing the actual maximum available bandwidth of the distribution path. 
         [0016]    Thus, the use of SDV typically means that the network paths through which content is delivered (e.g., multicast video content) dynamically changes depending upon which content the various network clients are requesting at any given time. In contrast, non-SDV systems typically provide static delivery paths for content. Moreover, it is generally desirable to provide for path and/or content redundancy, in the event that there is a point of failure somewhere along a delivery path. While path redundancy may be fairly straightforward in a static path environment, this is less easy to accomplish in a dynamic path environment such as an SDV delivery network. Various techniques for providing such redundancy will be described later in the present disclosure. 
         [0017]    Any of the above-mentioned functional blocks, including ERM  102 , SDVSM  103 , routers  106 A-B, QAMs  108 A-B, and client devices  110 , may each be implemented, for example, as a computer or as a system or device that includes a computer. The term “computer” as referred to herein broadly refers to any electronic, electro-optical, and/or mechanical device, or system of multiple physically separate or physically joined such devices, that is able to process and manipulate information, such as in the form of data. Non-limiting examples of a computer include one or more personal computers (e.g., desktop or laptop), servers, smart phones, personal digital assistants (PDAs), television set top boxes, and/or a system of these in any combination or subcombination. In addition, a given computer may be physically located completely in one location or may be distributed amongst a plurality of locations (i.e., may implement distributive computing). A computer may be or include a general-purpose computer and/or a dedicated computer configured to perform only certain limited functions. 
         [0018]    A computer typically includes hardware that may execute software and/or be configured in hardware to perform specific functions. The software may be stored on a computer-readable medium in the form of computer-readable instructions. A computer may read those computer-readable instructions, and in response perform various steps as defined by those computer-readable instructions. Thus, any functions attributed to any of the functional blocks of  FIG. 1  as described herein may be implemented, for example, by reading and executing such computer-readable instructions for performing those functions, and/or by any hardware subsystem (e.g., a processor) from which the computer is composed. 
         [0019]    The term “computer-readable medium” as used herein includes not only a single physical medium or single type of medium, but also a combination of one or more physical media and/or types of media. Examples of a computer-readable medium include, but are not limited to, one or more memories, hard drives, optical discs (such as CDs or DVDs), magnetic discs, and magnetic tape drives. 
         [0020]    Such a computer-readable medium may store computer-readable instructions (e.g., software) and/or computer-readable data (i.e., information that may or may not be executable). In the present example, a computer-readable medium (such as memory) may be included in any one or more of the functional blocks shown in  FIG. 1  and may store computer-executable instructions and/or data used by any of those functional blocks. Alternatively or additionally, such a computer-readable medium storing the data and/or software may be physically separate from, yet accessible by, any of the functional blocks shown in  FIG. 1 . 
         [0021]    Network  101  may be any type of network, and may be a single network or a combination of multiple networks, such as a cable and/or fiber optic and/or satellite television distribution network, a telephone network, and/or the Internet. Physically, network  101  may be embodied, for example, as multiple computers communicatively coupled together as a plurality of nodes in a wired and/or wireless manner. 
         [0022]    An example functional block diagram of a computer is shown in  FIG. 2 , in which the computer is shown to include a processor  201 , a communications interface  202 , storage  203 , and a user interface  204 . In this example, the computer-readable medium may be embodied by storage  203 , and processor  201  may execute computer-executable instructions stored by storage  203 . Communications interface  202  may provide for unidirectional or bidirectional communications with any network or device external to that computer. For example, communications interface  202  as embodied in router  106 A may provide communications between network  101  and router  106 A, as well as between router  106 A and QAMs  108 A and B. User interface  204  may allow for unidirectional or bidirectional information transfer between the computer and a human user, such as via a display or a keyboard. Again, any of the functional blocks of  FIG. 1  may be implemented as a computer such as shown in  FIG. 2 . 
         [0023]      FIGS. 3A-D  are signaling diagrams showing illustrative interactions between functional blocks of  FIG. 1 , and  FIG. 4  is a flow chart showing illustrative steps that may be performed by the system of  FIG. 1 . 
         [0024]    With reference to  FIGS. 1-4 , in block  401  ( FIG. 4 ), the flow diagram may include one of the client devices  110  requesting a video program by communicating a program request  302  to SDVSM  103 . In  FIGS. 3A-D , the program request  302  may include a source identifier (source ID) of the requested source providing the video program of interest. Table I, below, provides information on example sources  104  and the services offered by each. Sources A and B, for instance, both provide the same Entertainment programming but have different source Internet Protocol (IP) addresses. 
         [0000]    
       
         
               
               
               
               
               
               
             
           
               
                 TABLE I 
               
               
                   
               
               
                   
                   
                 Source 
                 Multicast Group  
                 Source IP 
                 Program 
               
               
                 Source 
                 Service 
                 ID 
                 IP address 
                 address 
                 Number 
               
               
                   
               
             
             
               
                 A 
                 Entertain- 
                  4163 
                 232.96.36.39: 
                  69.240.57.203 
                 1 
               
               
                   
                 ment 
                   
                 4039 
                   
                   
               
               
                   
                 program- 
                   
                   
                   
                   
               
               
                   
                 ming 
                   
                   
                   
                   
               
               
                 B 
                 Entertain- 
                  4163 
                 232.96.36.39: 
                 169.240.57.203 
                 1 
               
               
                   
                 ment 
                   
                 4039 
                   
                   
               
               
                   
                 program- 
                   
                   
                   
                   
               
               
                   
                 ming 
                   
                   
                   
                   
               
               
                 C 
                 News 
                 12153 
                 232.96.36.1: 
                  69.240.57.194 
                 1 
               
               
                   
                 program- 
                   
                 4001 
                   
                   
               
               
                   
                 ming 
               
               
                   
               
             
          
         
       
     
         [0025]    To request a particular program, the client device  110  may, for example, communicate the program request  302  to the SDVSM  103 , requesting to tune to source ID 12153 (which identifies a News program from source C). The Source IP address may be a network address of a source  104  providing a multicast transporting the requested program. The Multicast Group IP address may be a destination network address of the group receiving the multicast, and the program number may be a place holder for an MPEG program number 
         [0026]    In block  402 , the flow diagram may include the SDVSM  103  processing the program request  302  and communicating an ERM program setup request  304  to the ERM  102 . In an example embodiment, the SDVSM  103  may determine whether the requested source ID is already being switched (i.e., not being provided) to another client device  110  of the same head end  150 . If not, then the SDVSM  103  sends the ERM program setup request  304  to the ERM  102  including the source ID of the source  104  providing the requested program. 
         [0027]    In block  403 , the flow diagram may include the ERM  102  processing the ERM program setup request  304  and determining a redundant join type for the requested program. In an example embodiment, the ERM  102  may determine one of four redundant join types: (1) a single-source multicast, concurrent join as described in connection with blocks  404   a - 409   a  of  FIG. 4  and  FIG. 3A ; (2) a single-source multicast, serial join as described in connection with blocks  404   b - 409   b  of  FIG. 4  and  FIG. 3B ; (3) a dual-source multicast, concurrent join as described in connection with blocks  404   c - 409   c  of  FIG. 4  and  FIG. 3C ; or a (4) a dual-source multicast, serial join as described in connection with blocks  404   d - 409   d  of  FIG. 4  and  FIG. 3D . 
         [0028]    The ERM  102  may determine the redundant join type based on various factors such as, but not limited to, whether multiple sources are available that provide the same requested program, the present balance of traffic on video interface inputs X, Y, and Z of the QAM  108  and/or in the network  101  and/or the head end  150 , and a service level purchased by a subscriber associated with the requesting client device  110 . 
         [0029]    In a concurrent join, as further described below, the QAM  108  is concurrently joined to, and therefore simultaneously receives, two redundant multicasts carrying the same program. If the QAM  108  fails to receive one of the two multicasts, the QAM  108  can rapidly switch and provide the other multicast, already being received by the QAM  108 , to the client device  110  with minimal or no service disruption. In comparison, in a serial join, the QAM  108  is initially joined to, and thus only initially receives, a single multicast carrying a program. If the multicast fails, the QAM  108  may request that a second multicast be provided over a different path and/or from a different source  104 . While a serial join can consume less bandwidth than a concurrent join, a larger service disruption may occur in a serial join before the second multicast can be established, as compared with a concurrent join. For this reason, a serial join may correspond to a lower service level than a concurrent join. 
       Single-Source Multicast, Concurrent Join 
       [0030]    Where a single-source multicast, concurrent join is chosen in block  403 , the flow diagram may include in step  404   a  the ERM  102  requesting the QAM  108  to set up a single-source multicast concurrent join. Referring to  FIG. 3A , this request is represented by the ERM  102  communicating a QAM program setup request  306  identifying a join type instructing the QAM  108  to set up a single-source multicast, concurrent join. 
         [0031]    In response to the setup request  306 , the QAM  108  may, in block  405   a , join two multicasts that each transport the requested program and that are received via different paths, hereafter referred to respectively as primary and secondary paths. Prior to joining the multicasts in this manner, the QAM  108  may configure two of its video interface inputs (e.g., X and Z) to respectively receive primary and secondary multicasts. The multicast received over the primary path will be referred to herein as a primary multicast  312 P, and the multicast received over the secondary path will be referred to herein as a secondary multicast  312 S. The primary and secondary paths may be different paths across the system between the source  104  providing the multicast and the QAM  108  receiving the multicast. For example, the multicasts  312 P and  312 S may pass through different routers  106 . In  FIG. 1 , for instance, source  104 A may provide a primary multicast  312 P routed through router  106 A and received at video interface input X of QAM  108 A, and a secondary multicast  312 S routed through router  106 B and received at video interface input Z of QAM  108 A. In another example, the primary and secondary paths may both pass through the same router (e.g., router  106 A), but may be forwarded to different video interface inputs (e.g., X and Y) of QAM  108 A via different links. While the former example provides less opportunities for a single point of failure, either configuration is possible. As such, the primary and secondary paths may pass through one or more common network elements and links, but the paths taken by those multicasts may differ in at least some way. 
         [0032]    To join a multicast, the QAM  108  may communicate a join request  308  to the source  104  via the network  101 , identifying a multicast to join that transports the requested program and the video interface inputs configured to receive the primary and secondary multicasts  312 P and  312 S. The QAM  0108  may also communicate an ERM program setup response  310  to the ERM  102 , but may or might not include multicast transport headers for both the primary and secondary multicasts  312 P and  312 S and the video interface inputs configured to receive the multicasts  312 P and  312 S. The ERM program setup response  310  may include a frequency and program number used by the client device  110  to tune to the requested program. The ERM  102  also might not respond to the ERM program setup response  310  from the QAM  108  when operating in pessimistic mode until receiving a multicast transporting the requested video. For example, in optimistic session setup, the QAM  108  may return the ERM program setup response  310  to the ERM  102  before it has acquired video even though no video is yet present on its output. In pessimistic session setup, the QAM  108  may not return the session setup response to the ERM  102  until it has acquired video and video is present on its output. 
         [0033]    Next, in block  406   a , the client device  110  receives the requested program. In an illustrative embodiment, the source  104  may communicate the primary multicast  312 P of the requested program to the head end  150  via the network  101 . The source  104  may also communicate the secondary multicast  312 S of the requested program to the head end  150  via the network  101 . For example, to generate the primary and secondary multicasts  312 P and  312 S, the single source  104  may provide the primary and secondary multicasts  312 P and  312 S to different network ports on different routers. Also, the primary and secondary multicasts  312 P and  312 S may be of different quality of video, with one being of higher quality than the other. The multicasts  312 P and  312 S may traverse different network paths when transmitted via a UDP datagram, which may propagate through the network  101  via multiple paths, and may arrive in a pseudo-random, or even a random order. 
         [0034]    The QAM  108  may detect data of the primary multicast  312 P on the video interface input configured to receive the primary multicast  312 P, and may forward the primary multicast  312 P to the client device  110 . The QAM  108  may also convert that primary multicast  312 P to a radio frequency (RF) video signal and transmit the RF video signal to the client device  110 . In response to initially detecting receipt of multicasts  312 P and  312 S, the QAM  108  may send an announce message  314  to the ERM  102  including a multicast header of each of the primary and secondary multicasts  312 P and  312 S successfully joined over the primary and secondary paths. In an example, a multicast header may include one or more of a multicast address of the requested program or service, a multicast port of the requested program or service, a multicast program of data within a transport stream (e.g., MPEG-2 stream), a source address from which data of the multicast is streamed, bandwidth (e.g., bits per second), and a destination address of a physical port on which a join request is sent. The ERM  102  may send an announce response  316  to the QAM  108  and respond to the SDVSM  103  with an SDVSM program setup response  318 . The SDVSM  103  may communicate a program confirm message  320  in response to receiving the SDVSM program setup response  318 . The program confirm message  320  may include a frequency and a program number, which the client device  110  may use to tune to the requested source ID transporting the requested program. 
         [0035]    At some point during providing the primary multicast to the requesting client device, the QAM  108  may detect a failure of the primary multicast at block  407   a . The failure may be of a link or some network element between the source  104  and the QAM  108  on the primary path, or of the video interface input receiving the primary multicast  312 P. To determine that a failure has occurred, the QAM  108  may determine that the primary multicast  312 P has not been received for a predetermined amount of time, such as for at least one millisecond, or for at least one second. Thus, a problem with the primary multicast signal that does not occur for at least the predetermined period of time may not be considered to qualify as a failure. A failure may be considered to have occurred not only based on a loss of the primary multicast signal, but alternatively based on a reduction in quality of the received video program carried by the primary multicast signal. 
         [0036]    In response to detecting the failure, the QAM  108  may fail over in block  409   a  to the secondary multicast  312 S, and may begin forwarding the already-joined secondary multicast  312 S to the requesting client device  110 . Because the primary and secondary multicasts  312 P and  312 S are concurrently joined, the QAM  108  is already receiving the secondary multicast  312 S at the time of the failure and can quickly begin providing the secondary multicast  312 S to the client device  110  to reduce or eliminate a disruption in service. The QAM  108  may also communicate an announce failover message  322  to the ERM  102  that includes the multicast transport header of the secondary multicast  312 S. The ERM  102  may respond with an announce failover response  324 . 
         [0037]    If the QAM  108  initially detects a failure prior to being capable of forwarding the primary multicast  312 P to the client device  100 , the QAM  108  may failover to the secondary multicast  312 S. In such a scenario, with reference to  FIG. 3A , the QAM  108  may not communicate announce message  314  and may not receive announce response  316 . Instead, upon detecting the failure, the QAM  108  may forward the secondary multicast  312 S to the client device  110 , and may communicate the announce failover message  322  to the ERM  102 . The ERM  102  may respond with the announce failover response  324  and may communicate the SDVSM program setup response  318  to the SDVSM  103 . The SDVSM  103  may then communicate the program confirm message  320  to the client device  110 , as discussed above. Further, if there is the single source  104 A fails, then the client device  110  may signal loss of the channel to the SDVSM  103 , and the SDVSM  103  may instruct the client device  110  to tune to a safe channel. 
       Single-Source Multicast, Serial Join 
       [0038]    Referring again to  FIG. 4 , in block  403 , the ERM may alternatively determine a join type of a single-source multicast, serial join for a requested program and so in block  404   b , the ERM  102  may request the QAM  108  to set up a single-source multicast, serial join, which is also described in  FIG. 3B .  FIG. 3B  differs from  FIG. 3A  as to when the secondary multicast  312 S is joined. In  FIG. 3A , the QAM  108  attempts to join the secondary multicast  312 S when (or shortly after) joining the primary multicast  312 P, without waiting for a failure of the primary multicast  312 P, and hence the QAM  108  may concurrently receive the primary and secondary multicasts  312 P and  312 S prior to such a failure. In  FIG. 3B , the QAM  108  does not join the secondary multicast  312 S until a failure is identified for the primary multicast  312 P. 
         [0039]    Next, in block  405   b , the QAM  108  may join a primary multicast  312 P. In an example embodiment, the QAM  108  may configure two of its video interface inputs (e.g., X and Z) to respectively receive the primary and secondary multicasts  312 P and  312 S via the primary and secondary paths. Once configured, the QAM  108  may communicate a join request  308 A to the source  104  via the network  101  to join the primary multicast  312 P, but does not yet request to join the secondary multicast  312 S. The QAM  108  may also communicate an ERM program setup response  310  to the ERM  102 , but may or might not include a multicast transport header for the primary multicast  312 P and the video interface inputs configured to receive multicast  312 P. The ERM  102  also might not respond to the ERM program setup request  310  from the QAM  108  when operating in pessimistic mode until receiving a multicast transporting the requested video. 
         [0040]    Next, in block  406   b , the client device  110  may receive the program. In an example embodiment, the source  104  may provide the primary multicast  312 P of the requested program to the head end  150  via the network  101 . The QAM  108  may detect primary multicast  312 P on the video interface input specified in the join request  308 , and may forward the primary multicast  312 P to the client device  110 . In response to initially detecting receipt of multicast  312 P, the QAM  108  may send an announce message  314  to the ERM  102  including a multicast header of the primary multicast  312 P. The ERM  102  may then send an announce response  316  to the QAM  108  and respond to the SDVSM  103  with an SDVSM program setup response  318 . The SDVSM  103  may communicate the program confirm message  320  in response to the SDVSM program setup response  318 , as discussed above. 
         [0041]    Next, in block  407   b , the QAM  108  may detect a failure of the primary multicast, in the same manner as discussed above with regard to block  407   a.    
         [0042]    In block  408   b , in response to detecting the failure, the QAM  108  may join the secondary multicast  312 S, and may communicate a second join request  308 B to the source  104 . The second join request  308 B may specify the video interface input (e.g., input Z) previously allocated in block  405   b  to receive the secondary multicast  312 S. The QAM  108  may then receive the secondary multicast  312 S from the source  104  over the secondary path. 
         [0043]    In block  409   b , once joined to the secondary multicast  312 S, the QAM  108  may then fail over to the secondary multicast  312 S via the secondary path, and may output the secondary multicast  312 S to the client device  110 . The QAM  108  may also communicate an announce failover message  322  to the ERM  102  that includes the multicast transport header of the secondary multicast  312 S. The ERM  102  may send an announce response  316  to the QAM  108  and respond to the SDVSM  103  with an SDVSM program setup response  318 . 
         [0044]    If the QAM  108  initially detects a failure prior to being capable of forwarding the primary multicast  312 P to the client device  100 , the QAM  108  may failover to the secondary multicast  312 S. In such a scenario, with reference to  FIG. 3B , the QAM  108  may not communicate announce message  314  and may not receive announce response  316  from the ERM  102 . Instead, upon detecting the failure, the QAM  108  may send join request  308 B to the source  104 , and may begin receiving the secondary multicast  312 S. The QAM  108  may forward the secondary multicast  312 S to the client device  110 , and may communicate the announce failover message  322  to the ERM  102 . The ERM  102  may respond with the announce failover response  324  and may communicate the SDVSM program setup response  318  to the SDVSM  103 . The SDVSM  103  may then communicate the program confirm message  320  to the client device  110 , as discussed above. 
       Dual-Source Multicast, Concurrent Join 
       [0045]    Referring again to  FIG. 4 , in block  403 , the ERM may alternatively determine a join type of a dual-source multicast, concurrent join for a requested program, and so in block  404   c , the ERM  102  may request the dual-source multicast, concurrent join, which is also described in  FIG. 3C .  FIG. 3C  differs from  FIGS. 3A-B  by including two different sources  104 A and  104 B providing the primary and secondary multicasts  312 P and  312 S, respectively, instead of a single source providing both the primary and secondary multicasts  312 P,  312 S. 
         [0046]    In block  405   c , in this case the QAM  108  may join primary and secondary multicasts  312 P and  312 S, respectively, being provided by different sources  104 A and  104 B. In an example embodiment, the QAM  108  may configure two of its video interface inputs (e.g., X and Z) to respectively receive the multicasts  312 P and  312 S via the primary and secondary paths. As above, the multicasts  312 P and  312 S may transport the same program, even though the program is being received from different sources  104 A and  104 B. Alternatively, the multicasts  312 P and  312 S may be related to each other, such as one being a national advertising version of a video program and the other being a local advertising version of the same video program. Once the video interface inputs are configured, the QAM  108  may communicate join request  308 A to source  104 A and join request  308 B to source  104 B. Each join request  308 A and  308 B may specify the multicast to join and a video interface input over which to receive the multicast. The QAM  108  may also communicate an ERM program setup response  310  to the ERM  102 , but may or might not include multicast transport headers for each of the primary and secondary multicasts  312 P and  312 S and the video interface inputs configured to receive multicasts  312 P and  312 S. The ERM  102  also might not respond to the ERM program setup request  310  from the QAM  108  when operating in pessimistic mode until receiving a multicast transporting the requested video. 
         [0047]    In block  406   c , the client device  110  may receive the video program. In an illustrative embodiment, the source  104 A may provide the primary multicast  312 P of the requested program to the head end  150  via the network  101 . The source  104 B may also provide the secondary multicast  312 S of the requested program to the head end  150  via the network  101 . The QAM  108  may detect the primary multicast  312 P on its video interface input specified in the join request  308 A, and may forward the primary multicast  312 P to the client device  110 . In response to initially detecting receipt of multicasts  312 P and  312 S, the QAM  108  may send an announce message  314  to the ERM  102  including a multicast header for each of the successfully joined multicasts  312 P and  312 S. The ERM  102  may send an announce response  316  to the QAM  108  and respond to the SDVSM  103  with an SDVSM program setup response  318 . The SDVSM  103  may communicate the program confirm message  320  in response to the SDVSM program setup response  318 , as discussed above. 
         [0048]    In block  407   c , the QAM  108  may detect a failure, in a manner as already described above. 
         [0049]    In block  409   c , in response to detecting a failure, the QAM  108  may fail over to the secondary multicast, and may output the secondary multicast  312 S to the client device  110 . The QAM  108  may also communicate an announce failover message  322  to the ERM  102  that includes the multicast transport header of the secondary multicast  312 S. The ERM  102  may respond with an announce failover response  324 . 
         [0050]    If the QAM  108  initially detects a failure prior to being capable of forwarding the primary multicast  312 P to the client device  100 , the QAM  108  may failover to the secondary multicast  312 S. In such a scenario, with reference to  FIG. 3C , the QAM  108  may not communicate announce message  314  and may not receive announce response  316 . Instead, upon detecting the failure, the QAM  108  may forward the secondary multicast  312 S to the client device  110 , and may communicate the announce failover message  322  to the ERM  102 . The ERM  102  may respond with the announce failover response  324  and may communicate the SDVSM program setup response  318  to the SDVSM  103 . The SDVSM  103  may then communicate the program confirm message  320  to the client device  110 , as discussed above. 
       Dual-Source Multicast, Serial Join 
       [0051]    Referring again to  FIG. 4 , in block  403 , the ERM may determine a join type of a dual-source multicast, serial join for a requested program, and so in block  404   d , the ERM  102  may request QAM  108  set up the dual-source multicast, serial join, which is also described in  FIG. 3D . In  FIG. 3D , the ERM  102  may, for example, communicate a QAM program setup request  306  identifying a join type instructing the QAM  108  to set up a dual-source multicast, serial join. 
         [0052]    In block  405   d , the QAM  108  may join a primary multicast  312 P via a primary path. In an example embodiment, the QAM  108  may configure two of its video interface inputs (e.g., X and Z) to respectively receive the multicast via the primary and secondary paths. Once configured, the QAM  108  may communicate a join request  308 A to the source  104 A via the network  101  specifying the multicast to join and a video interface input (e.g., input X). The QAM  0108  may also communicate an ERM program setup response  310  to the ERM  102 , but may or might not include a multicast transport header for the primary multicast  312 P and the video interface input configured to receive the multicast  312 P. The ERM  102  also might not respond to the ERM program setup request  310  from the QAM  108  when in pessimistic mode until receiving a multicast transporting the requested video. 
         [0053]    In block  406   d , the client device  110  may receive the program. In an example embodiment, the source  104  may provide the primary multicast  312 P of the requested program to the head end  150  via the network  101 . The QAM  108  may detect data of the primary multicast  312 P on the video interface input specified in the join request  308 A, and may forward the primary multicast  312 P to the client device  110 . In response to initially detecting receipt of multicast  312 P, the QAM  108  may send an announce message  314  to the ERM  102  including a multicast header of primary multicast  312 P. The ERM  102  may also send an announce response  316  to the QAM  108  and respond to the SDVSM  103  with an SDVSM program setup response  318 . The SDVSM  103  may communicate the program confirm message  320  in response to the SDVSM program setup response  318 , as discussed above. 
         [0054]    In block  407   d , the QAM  108  may detect a failure, in a manner as already discussed above. 
         [0055]    In block  408   d , and in response to detecting the failure, the QAM  108  may join the secondary multicast  312 S, and may communicate a second join request  308 B to the source  104 B. The second join request  308 B may specify the video interface input (e.g., input Z) previously allocated in block  405   d  to receive the secondary multicast  312 S. The QAM  108  may then receive the secondary multicast  312 S from source  104 B. 
         [0056]    In block  409   d , the QAM  108  may fail over to the secondary multicast, and may output the secondary multicast  312 S to the client device  110 . The QAM  108  may also communicate an announce failover message  322  to the ERM  102  that includes the multicast transport header of the secondary multicast  312 S. The ERM  102  may respond with an announce failover response  324 . 
         [0057]    If the QAM  108  initially detects a failure prior to being capable of forwarding the primary multicast  312 P to the client device  100 , the QAM  108  may failover to the secondary multicast  312 S. In such a scenario, with reference to  FIG. 3D , the QAM  108  may not communicate announce message  314  and may not receive announce response  316 . Instead, upon detecting the failure, the QAM  108  may send join request  308 B to the source  104 B, and may begin receiving the secondary multicast  312 S. The QAM  108  may forward the secondary multicast  312 S to the client device  110 , and may communicate the announce failover message  322  to the ERM  102 . The ERM  102  may respond with the announce failover response  324  and may communicate the SDVSM program setup response  318  to the SDVSM  103 . The SDVSM  103  may communicate the program confirm message  320  to the client device  110 , as discussed above. 
         [0058]    One or more aspects of the above examples may be embodied in computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices such as by any of the blocks in  FIG. 1 . Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The computer executable instructions may be stored on a computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, RAM, etc. As will be appreciated by one of skill in the art, the functionality of the program modules may be combined or distributed as desired in various embodiments. In addition, the functionality may be embodied in whole or in part in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA), application specific integrated circuits (ASIC), and the like. 
         [0059]    While embodiments have been described with respect to specific examples including presently preferred modes of carrying out the invention, those skilled in the art will appreciate that there are numerous variations and permutations of the above described systems and techniques. Thus, the spirit and scope of the invention should be construed broadly as set forth in the appended claims.