This file is raw output from pdftotext and may not be ideal for distribution. If you are a maintainer for Hackipedia, please sit down when you have time and clean this text version up. Source PDF: /mnt/main/jmc-storage/docs/DVB/DVB A152 Server-Based Fast Channel Change for DVB-IPTV Systems (August 2010).pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. --------------------------------------------------------------- ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Digital Video Broadcasting (DVB); Server-Based Fast Channel Change for DVB-IPTV Systems DVB Document A152 August 2010   Server-­based  Fast  Channel  Change  for  DVB-­IPTV  Systems     T able of Contents Server-based Fast Channel Change for DVB-IPTV Systems ........................................................................... 1 1 Scope ........................................................................................................................................................ 2 2 References ................................................................................................................................................ 2 3 Definitions and Abbreviations ................................................................................................................. 2 4 Server-based FCC : detailed solution description .................................................................................... 3 4.1 Introduction ........................................................................................................................................................ 3 4.2 DVB server-based FCC solution principle ......................................................................................................... 3 4.3 DVB server-based FCC and DVB LMB RET ................................................................................................... 4 4.4 Server-based FCC architecture........................................................................................................................... 5 4.4.1 IETF and DVB terminology ......................................................................................................................... 5 4.5 FCC/ (LMB RET) unicast repair RTP sessions ................................................................................................. 6 4.6 RAMS RTCP FB signaling for DVB FCC ........................................................................................................ 6 4.7 RAMS RTCP FB message formats .................................................................................................................... 8 4.7.1 Feedback Control Information for RAMS-R ................................................................................................ 9 4.7.2 Feedback Control Information for RAMS-I ............................................................................................... 10 4.7.3 Feedback Control Information for RAMS-T .............................................................................................. 11 4.8 HNED RTCP reporting for DVB FCC (/LMB RET) ....................................................................................... 11 4.9 FCC RTP burst ................................................................................................................................................. 12 4.9.1 Terminating the burst.................................................................................................................................. 12 4.9.2 Burst packet loss recovery .......................................................................................................................... 12 4.10 Retransmission session transport address and SSRC identifiers ...................................................................... 12 4.11 RTSP and FCC ................................................................................................................................................. 13 4.12 QoS Priority settings ........................................................................................................................................ 14 4.13 FCC (/LMB RET) Service discovery ............................................................................................................... 14 4.13.1 By means of DHCP FCC(/LMB Retransmission Server) Address option ................................................. 14 4.13.2 Via SD&S ................................................................................................................................................... 14 4.13.3 By means of RTCP RSI messages .............................................................................................................. 14 4.14 SD&S FCC (/LMB RET) parameters overview .............................................................................................. 15 5 Server based FCC: SD&S broadcast discovery record parameters........................................................ 16 DVB BlueBook A152 1 1 Scope The present document contains the specification for an optional extension to the DVB-IPTV handbook [1] which facilitates a faster rendering when moving from one multicast LMB IPTV service to another or joining a multicast LMB IPTV service, i.e. enables fast channel change. The specification is not a necessary part of the DVB-IPTV system, but-is provided to enhance performance of an otherwise functional system. The specifications that are provided are not necessarily restricted to use with DVB IPTV systems, but may be fully or partially applicable to other forms of DVB broadcast service. The mechanisms may also be applicable to other types of service than IPTV, including audio only services and streamed data services. In order to implement the specifications in this document, extensions to the platform will be required in both servers and clients over and above those needed for the most basic of multicast IPTV service delivery as described in [1]. These extensions may include additions to both hardware and software capabilities. In any implementation where these extensions are not available in either the client, the server, or both, then the overall IPTV service is not affected, but the rapid switching of service is not available and the channel change time is exactly as it would have been if the basic service described in [1] were provided. It must be noted that a specific ordering of the MPEG2 TS packets transported in the LMB service (PAT/PMT, ECM/EMM, etc) may facilitate a more efficient demuxing, descrambling and decoding pipeline at the HNED. This applies both to the LMB service without FCC and to the LMB service enhanced with FCC. MPEG2 TS packet ordering in the IP multicast stream is under control of the head-end, implementation-dependent and outside the scope of this document 2 References [1] [2] IETF RAMS internet draft : Unicast-Based Rapid Acquisition of Multicast RTP Sessions (http://tools.ietf.org/html/draft-ietf-avt-rapid-acquisition-for-rtp-10 [3] RFC 5760 : RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback [4] RFC 5506 : Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences [5] RFC 4585 : Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) [6] RFC 4588 : RTP Retransmission Payload Format [7] RFC 5761 : Multiplexing RTP Data and Control Packets on a Single Port 3 Definitions and Abbreviations A L-F E C : Application Layer Forward Error Correction D V B-IP service: A DVB service provided over IP or content on demand over IP. R A M S: Rapid Acquisition of Multicast RTP sessions; the RTCP FB messages and protocol as defined in IETF RAMS draft [2], for rapid acquisition of RTP multicast session F B : Feedback F C C : Fast Channel Change DVB BlueBook A152 2 D V B F C C client: The part of the HNED that makes use of the RAMS protocol to request, receive and control a burst of unicast RTP packets from a DVB FCC server, a process that is initiated before the normal LMB connection process is initiated. D V B F C C server : Interacts with the DVB FCC client through RAMS and provides the RTP burst from its cache. L M B : Live Media Broadcast L M B R E T : LMB Retransmission as defined in annex F of this document Primary M ulticast Session: A SSM session which RTP receivers can join at a random point in time. R A P: Random Access Point, which represents an Intra-encoded (I)-frame R R: Receiver Report RTCP message RSI: Receiver Summary Information RTCP message R T C P: Real-Time Transport Control Protocol R T P: Real-Time Transport Protocol SD ES: Source Description RTCP message SR: Sender Report RTCP message SSM : Source-Specific Multicast T L V: Type Length Value 4 Server-based FCC : detailed solution description 4.1 Introduction This method describes a solution by which the typical delay for an LMB service acquisition process is reduced by means of having a DVB FCC client interact with a DVB FCC server prior to the normal LMB connection process. It is based on RTP/RTCP and has many commonalities with the DVB LMB RET solution. This specification addresses the DVB FCC solution based on a client-server paradigm, and is only applicable to LMB services that are transported over RTP. 4.2 DVB server-based FCC solution principle The DVB server-based FCC solution operates as follows: the DVB FCC server caches the most recent data transported in the multicast of each LMB service prior to connecting to the LMB service by means of IGMP, the HNED makes a request to a DVB FCC server the server s its cache to the requesting HNED. This burst will start with a RAP. This eliminates any waiting time that is generally present when the HNED connects directly to a primary multicast of the LMB service, resulting in the improved response time of the Fast Channel Change Service. while and around that time, the HNED will join the primary multicast of the LMB service. There are dedicated RTCP RAMS FB messages exchanged between the HNED and the FCC server for requesting, controlling and terminating the burst. DVB BlueBook A152 3 4.3 DVB server-based FCC and DVB LMB RET The DVB server-based FCC solution has many commonalities with DVB LMB RET unicast repair because both solutions leverage the same protocol/architecture concepts. The main aspects of these common protocol/architecture concepts are specified in: RFC 4585: Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)[5] RFC 4588: RTP Retransmission Payload Format[6] RFC 5760: RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback[3] The DVB server-based FCC solution leverages the IETF AVT WG RAMS draft (Unicast-Based Rapid Acquisition of M ulticast RTP Sessions) [2]. The RAMS draft specifies the interactions between an RTP receiver defines new RAMS RTCP FeedBack messages (RAMS-R, -I and -T) for controlling the burst process. is responsible for sending the RTP burst (resulting in the FCC experience) but also for sending retransmissions in response to retransmission requests. The RAMS draft stipulates that RTP retransmissions and RTP burst packets are transmitted in one and the same unicast RTP (retransmission) session, with the RTP burst packets formatted with a retransmission payload header (RFC 4588). DVB server-based FCC will not deviate from these rules, which means that when both the RET and FCC services are offered for a DVB LMB service, and a HNED makes use of both these services: The DVB LMB RET server and DVB FCC server coincide and are one and the same 1. This server will be referred to in this text as the DVB FCC (/LMB RET) server Unicast RET packets and FCC burst packets are transported by the DVB FCC (/LMB RET) server in the same unicast RTP retransmission session and are both formatted with a retransmission payload header as specified in RFC 4588. It must be stressed that the DVB LMB RET service and the DVB server-based FCC service remain decoupled in the sense that the DVB LMB RET service may be provided without DVB server-based FCC service and vice- versa. However, DVB does recommend that server-based FCC service is combined with LMB RET, specifically because there is no penalty for any of the network, client or server implementation in deploying the DVB LMB RET service on top of -based FCC service. In this section the focus is on the DVB server- based FCC solution, but because of the inherent ties into the LMB RET solution, there will also be some specific text in this annex with regard to unicast packet loss repair of the LMB RET solution. This text is provided in italics, and can be discarded where the FCC service is operated without support for LMB RET unicast repair. If both FCC and LMB RET services are offered, both the normative text in the RET specification and in the FCC specification in this document shall be followed. 1 bursting process is also the one responding to retra and for a given SSM RTP session and DVB-HNED, there can only be one active Feedback Target, this requirement is a logical consequence. DVB BlueBook A152 4 4.4 Server-based FCC architecture     F igure 1 D V B server-based F C C Figure 1 represents a high level view of the DVB server-based FCC architecture. The DVB server-based FCC solution relies on the RAMS protocol specified in the IETF RAMS draft [2]. When an end- the DVB FCC client in the HNED requests a unicast RTP burst from a DVB FCC server by means of a RAMS-Request (RAMS-R) RTCP FB message. If the request is not accepted, the DVB FCC server will send a RAMS-Information (RAMS-I) RTCP message containing a non-service response, and then the HNED resorts to the normal LMB service connection process. When accepting the request, the DVB FCC server starts bursting (i.e. forwarding at a higher rate than the streaming rate) unicast data from its cache that holds the most recent data of the LMB service starting with a Random Access Point, along with a RAMS-I RTCP message. This message may be used to signal to the DVB FCC client when the DVB FCC client should issue an IGMP join to connect to the LMB service. In this case the DVB FCC server will cease bursting the cached data at that point, as the unicast RTP stream has caught-up with the multicast stream carrying the LMB service data. Before or after reception of the first multicast packets of the LMB service by the DVB FCC client, it sends a RAMS-Termination (RAMS-T) message to the DVB FCC server, requesting it to terminate the RTP burst. 4.4.1 IETF and DVB terminology The IETF RAMS draft [2] uses the term for the RAMS messaging interaction with the RTP receiver and for the RTP burst transmission. In this document, terminology is applied, each being the equivalent of the retransm When is used, LMB RET services are available. to highlight that this annex describes the DVB FCC service solution, but bearing in mind that the same server is called LMB RET server (annex F in [1]) when the DVB LMB RET service is also provided. Similarly, in the remainder of this document, the is used. The choice not to r is made in order to differentiate - for which [1] in annex F has already introduced the term DVB BlueBook A152 5 4.5 FCC/ (LMB RET) unicast repair RTP sessions A DVB FCC (/RET) client that makes use of the DVB FCC service, is engaged in: A primary RTP multicast session2, where the HNED is an SSM RTP receiver and the FCC (/RET) client sends its RTCP messages unicast to the RTCP FB target of that SSM, a logical entity that is part of the DVB FCC(/LMB RET) server, and defined in RFC 5760. These RTCP messages sent by the HNED are o the RAMS-Request RTCP FB message for requesting a burst, o the NAC K RTCP F B message when the LMB RET service is activated and supported, o the other more generic RTCP messages (RTCP RR, RTCP SDES, RTCP Bye), as explained in the LMB RET annex, section F4 of TS 102034. A unicast retransmission session where the burst/retransmission source logical entity of the DVB FCC server sends the RTP burst packets, and in which the RAMS-I and RAMS-T messages are exchanged, as well as the RTCP SR/RR, RTCP SDES and RTCP Bye messages, pertaining to this session. When the LMB RET service is present, the unicast RTP RET (RET service) packets are also transmitted in this unicast retransmission session 4.6 RAMS RTCP FB signaling for DVB FCC Following IETF RAMS draft [2], an FCC client-enabled HNED shall support the RAMS-R, RAMS-I and RAMS-T RTCP FB messages. Figure 2 depicts the basic RAMS FB message interactions between the DVB FCC (/RET) client and the DVB FCC (/LMB RET) server. FCC  server Multicast Burst   FB Router FCC  client Source Source Target RTP  Multicast RTCP  RAMS-­‐R RTCP  RAMS-­‐I RAMS -­‐I  can  be  transmitted   before  or  during  RTP  burst Unicast RTP  burst IGMP  join RTP  Multicast RAMS -­‐ T  can  be  transmitted  before   RTCP  RAMS-­‐T or  after  the    RTP  MC  is  joined   F igure 2 Basic R A M S messaging between D V B F C C(/R E T) client and D V B F C C (/L M B R E T) server The formats of the RAMS messages are described in the next section. The FCC (/RET) client in the HNED starts the RAMS interaction by issuing a RAMS-R message towards the FB target logical entity that is part of the FCC(/LMB RET) server. 2 in DVB RET terminology (annex F of the IPTV handbook 102034) this session is DVB BlueBook A152 6 The FCC(/LMB RET) server is required to transmit at least one RAMS-I message, and when accepting the request, it also starts bursting the RTP data from its cache. In that case, the RAMS-I message shall include a field indicating the RTP sequence number (SN) of the 1st packet transmitted in the unicast burst. The FCC(/RET) client needs to transmit a RAMS-T message, explicitly requesting the FCC (/LMB RET) server to stop the FCC burst. When the FCC client starts receiving the multicast stream prior to sending the RAMS-T message, the RAMS-T message shall include the field containing the RTP SN of the 1 st packet received in the primary multicast stream. See the IETF RAMS draft [2] for a detailed overview of the RAMS protocol interaction, including possible corner cases. Figure 3 shows the (basic) RAMS messaging between FCC(/RET) client and FCC(/LMB RET) server, and also (optional) Exchange of RAMS-R update RTCP FB message, allowing an FCC(/RET) client to request adjusting the bursting rate with optionally a corresponding response by the FCC(/LMB RET) server (including a RAMS-I update RTCP FB message) Note that RAMS-R update and RAMS-I update messages have the same format definitions as respectively the RAMS-R and RAMS-I messages. DVB LMB RET interactions (only present when the LMB RET service is offered) where the F C C/RET client issues an RTCP F B NAC K message to the F B target logical entity of the F C C/LMB RET server, with the latter responding with one or several Retransmission Packets. DVB LMB RET service may be used by the HNE D to request missing packets detected in the multicast strea m or in the unicast burst. This could be for exa mple a gap that may have occurred between the end of the unicast burst and the start of reception of the primary multicast strea m by the HNE D. Transmission of RTCP Bye from the HNED FCC(/RET) client towards the FB target logical entity (in the primary RTP multicast session) and towards the burst/retransmission source logical entity of the FCC (/LMB RET) server (in the unicast retransmission session), when the HNED no longer wants to receive the LMB service (e.g. user zaps away). In this particular example the unicast burst was already terminated. Not indicated in the figure: RTCP RR, RTCP SR and RTCP SDES messages are also exchanged between the FCC(/RET) client and the FCC(/LMB RET ) server in both the multicast and the unicast retransmission session-, and the rules apply as stipulated in the LMB RET annex, section F4.2 of [1]. DVB BlueBook A152 7 LMB  RET  /  FCC  server HNED   Multicast Burst  /Retransmission FB Router with   Source Source Target RET/FCC    client RTP  Multicast RTCP  RAMS-­‐R RTCP  RAMS-­‐I RAMS-­‐I  can  be  transmitted   Unicast RTP  burst before  or  during  RTP  burst (RTCP  RAMS-­‐R) (RTCP  RAMS-­‐I) IGMP  join RTP  Multicast RAMS-­‐T  can  be  transmitted  before   RTCP  RAMS-­‐T or  after  the    RTP  MC  is  joined RTCP  FB  NACK Unicast RTP  Retransmission IGMP  join RTCP  Bye RTCP  Bye F igure 3 Basic R A M S messaging extended with R E T messaging and R T C P Bye 4.7 RAMS RTCP FB message formats The RAMS RTCP FB message formats follow the RTCP FB message format as defined in RFC 4585.   F igure 4 Generic Packet format for R T C P F B message Each feedback message has a fixed-length field for version, padding, feedback message type (FMT), payload type (PT), length, SSRC of packet sender, SSRC of media source as well as a variable-length field for feedback control information (FCI). In the RAMS messages, the PT field is set to RTPFB (205) and the FMT field is set to RAMS (6). Individual RAMS messages are identified by an 8-bit sub-field called Sub Feedback Message Type (SFMT), which is always the 1st field of the FCI information for RAMS. The second field is a 24 bit reserved field (for alignment). DVB BlueBook A152 8 With two exceptions (see further, RAMS-I), all subsequent information (sub-)fields in the FCI field are encoded as TLV elements as described below, and depicted in Figure 5. Type: A single-octet identifier that defines the type of the parameter represented in this TLV element. Length: A two-octet field that indicates the length (in octets) of the TLV element excluding the Type and Length fields, and the 8-bit Reserved field between them. Note that this length does not include any padding that is required for alignment Value: Variable-size set of octets that contains the specific value for the parameter. If a TLV element does not fall on a 32-bit boundary, the last word shall be padded to the boundary using further bits set to 0. 0                    1                    2                    3    01234567  89012345  67890123  45678901 +-­-­-­-­-­-­-­-­+-­-­-­-­-­-­-­-­+-­-­-­-­-­-­-­-­+-­-­-­-­-­-­-­-­+ |    Type    |Reserved|            Length          |   +-­-­-­-­-­-­-­-­+-­-­-­-­-­-­-­-­+-­-­-­-­-­-­-­-­+-­-­-­-­-­-­-­-­+   |        variable  data  -­-­-­-­    //|    0x00    | +-­-­-­-­-­-­-­-­+-­-­-­-­-­-­-­-­+-­-­-­-­-­-­-­-­+-­-­-­-­-­-­-­-­+ F igure 5 Format for T L V elements in R A M S messages Dedicated TLV elements are specified in this section, but note that private TLV elements may be defined too [2]. 4.7.1 Feedback Control Information for RAMS-R The RAMS Request message is identified by SFMT=1. The FCI field shall contain only one RAMS Request. The RAMS draft [2] has defined four TLV elements that can be embedded in the RAMS Request: Requested Media Sender SSRC (type = 1): Optional TLV element that in DVB system is only used when the HNED does not know the media sender SSRC of the primary multicast RTP stream carrying the LMB service. The length field shall be zero (i.e. there is no value field). When this TLV is present, the FCC server will ignore the media sender SSRC specified in the header of the RAMS-R message3 This TLV shall not be used by the HNED when the SSRC values of the primary multicast streams are signaled in SD&S. Min RAMS Buffer Fill Requirement (32 bits) (type = 2): Optional TLV element that denotes the minimum milliseconds of data that HNED desires to have in its buffer before allowing the data to be consumed by the application. Max RAMS Buffer Fill Requirement (32 bits) (type = 3): Optional TLV element that denotes the maximum milliseconds of data that HNED can buffer without losing the burst data due to buffer overflow. Max Receive Bitrate (64 bits) (type = 4): Optional TLV element that denotes the maximum bitrate (in bits per second) that the HNED can process the unicast burst. This rate should include whatever knowledge the HNED has that would provide an upper bound on the unicast burst bitrate. The limits may include local receiver limits as well as network limits that are known to the receiver. 3 When the FCC server cannot use the media sender SSRC field in the RAMS-R message to identify the primary multicast stream, the transport address of the RAMS-R shall provide that information, requiring a different tuple of FCC server IP address and port number for the Feedback Target entity for each primary multicast, when SSRCs are not signalled in SD&S. DVB BlueBook A152 9 4.7.2 Feedback Control Information for RAMS-I   F igure 6 F C I field syntax for the R A M S Information message The following fields are defined for the RAMS-I : SFMT (8 bits) : Value is 2 for RAMS-I Message Sequence Number (8 bits) : Mandatory field that denotes the sequence number of this RAMS-I message. During rapid acquisition, multiple RAMS-I messages (RAMS-I update) MAY be sent and/or the same RAMS-I message MAY be repeated. The first RAMS-I message SHALL have an MSN value of 0. This value SHALL NOT be changed if the same RAMS-I message is sent to the same HNED multiple times for redundancy purposes. If a new information is conveyed in a new RAMS-I message update, the MSN value SHALL be incremented by one. Response (16 bits): Mandatory field that denotes the RS response code for this RAMS-I message. Possible response codes are defined in [2] The TLV elements defined for RAMS-I are: Media Sender SSRC (32 bits) (type = 31): Optional TLV element that specifies the media sender SSRC of the unicast burst stream. While this information is already available in the message header, it may be useful to repeat it in an explicit field. For example, if the feedback target that received the RAMS-R message is associated with a single primary multicast stream but the requested media sender SSRC does not match the SSRC of the RTP stream associated with this feedback target, the FCC server should include this TLV element in the initial RAMS-I message to let the HNED know that the media sender SSRC has changed. If the two SSRCs match, there is no need to include this TLV element. RTP Seqnum of the First Packet (16 bits) (type = 32): TLV element that specifies the RTP sequence number of the first packet that will be sent in the retransmission session. This allows the HNED to know whether one or more packets sent by the FCC (/LMB RET) server have been dropped at the beginning of the retransmission session. This field is only present if the RAMS request was accepted by the FCC (/LMB RET) server. Earliest Multicast Join Time (32 bits) (type = 33): Optional TLV element that specifies the time difference (i.e., delta time, espressed in ms) between the arrival of the 1st RTP packet and the earliest time instant when the HNEDcould join the primary multicast session. A zero value in this field means that the HNED can join the primary multicast session right away. Note that if the RAMS request has been accepted, this field SHOULD be sent at least once, so that the HNED knows when to join the primary multicast session. If the burst request has been rejected as indicated in the Response field, this field MAY be omitted or set to 0. In that case, it is up to the HNED when or whether to join the primary multicast session. Burst Duration (32 bits)(type = 34): Optional TLV element that denotes the duration of the burst, i.e. the delta difference between the 1st and the last burst packet, that the FCC(/LMB RET) is planning to send (in ms). In the absence of additional stimulus, the FCC(/LMB RET) server will send a burst of this duration. However, the burst duration may be modified by subsequent events, including changes in the primary multicast stream and reception of RAMS-T messages. Note that the FCC(/LMB RET) server shall terminate the flow in a deterministic timeframe, even if it does not get an RAMS-T or a BYE from the HNED. DVB BlueBook A152 10 Max Transmit Bitrate (64 bits)(type = 35): Optional TLV element that denotes the maximum bitrate (in bits per second) that will be used for the burst. Note that the initial RAMS-I message should precede the unicast burst or be sent at the start of the burst. Subsequent RAMS-I message(s) may be sent during the unicast burst and convey changes in any of the fields. 4.7.3 Feedback Control Information for RAMS-T The RAMS Termination message is identified by SFMT=3. The FCI field shall contain only one RAMS Termination. Only one TLV field is defined for the RAMS-T. If prior to sending the RAMS-T message the HNED has already joined the primary multicast session and received at least one RTP packet from the multicast session, the HNED includes the sequence number of this first RTP packet in the RAMS-T message. With this information, the FCC(/LMB RET) server can decide when to terminate the unicast burst. If the HNED issues the RAMS-T message before it has joined and/or begun receiving RTP packets from the primary multicast session, the HNED does not specify any sequence number in the RAMS-T message, which indicates the FCC(/LMB RET) server shall stop the burst immediately. The only TLV defined for RAMS-T is: Extended RTP Seqnum of First Multicast Packet (32 bits) (type = 61): conditionally optional TLV element that specifies the extended RTP sequence number of the first multicast packet received by HNED. If no RTP packet has been received from the primary multicast session, this field is not present. 4.8 HNED RTCP reporting for DVB FCC (/LMB RET) For both the primary multicast session and the retransmission session, the HNED follows the RTCP reporting rules as defined by the early feedback profile AVPF [5], with the exception that the 1st RAMS-R message can be sent right at the beginning. Similar as is the case for DVB RET, a DVB FCC(/RET) client and server shall support reduced size RTCP reporting. The to signal to the HNEDs with SD&S whether the HNED may use reduced size RTCP reporting in the primary multicast session. However, the FCC(/RET) client shall transmit the RAMS-R and the Bye packet, when used in the primary multicast session , together with a SDES message..Note that reduced size reporting is only allowed and applicable for the primary multicast session. This means that The DVB FCC(/LMB RET) server shall send RAMS-I in (full) compound message format, i.e. including an SDES and SR message The DVB FCC(/LMB RET) client of the HNED shall send RAMS-T in (full) compound message format, i.e. including an SDES and RR message Note: issuing of RTCP RR messages by the HNED may be disabled through the -disable-rtcp- attribute. DVB recommends that for compound reporting for statistical purposes (comprising the SDES and RR message), this frequency be once every 5 seconds. A BYE packet shall only be sent by the HNED - DVB recommends the use of Bye for FCC(/RET) deployment. The BYE packet for the primary multicast RTP session and retransmission session, when used, is always sent out, together with an SDES, and also an RR if RR-reporting is enabled. DVB BlueBook A152 11 4.9 FCC RTP burst As defined in IETF RAMS draft [2], the RTP burst packets shall be formatted following RFC 4588, i.e. have the RTP retransmission payload header. When the LMB RET service is offered in addition to the DVB-F C C server- based method, the RET packets shall also be formatted as specified in RF C 4588. The bit rate used during the burst is entirely determined by the FCC(/LMB RET) server but may be calculated based on the information retrieved from RTCP RAMS-R message and dynamically adapted based on tracking other RTCP messages exchanged during the bursting process. This is outside the scope of this document. 4.9.1 Terminating the burst A FCC(/LMB RET) client that wishes to terminate the burst, can do this for two reasons: the FCC(/LMB RET) client will be joining or has recently joined the associated primary multicast, and hence sends out the RAMS-T message. This is part of the normal RAMS process. the HNED is no longer interested in the primary multicast and associated burst (e.g. the end-user switched to a different LMB service while the burst was still received). In this case the FCC(/LMB RET) client shall transmit an RTCP Bye message to the FCC(/LMB RET) server , both in the primary multicast session and in the retransmission session, even when the FCC(/LMB RET) client already issued a RAMS-T message. Note that sending the RAMS-T message may be omitted by the FCC(/LMB RET) client, when the HNED transmits the Bye messages whilst still receiving the RTP burst. 4.9.2 Burst packet loss recovery There may be packet loss occurring in the RTP unicast burst, or resulting from a non-seamless switch over from the unicast burst to the primary multicast stream by the HNED. If the DVB LMB RET service is offered, the HNE D F C C/RET client can request the missing packet(s) by issuing (an) RTCP F B NAC K message(s) to the F C C/LMB RET server. In this message each reported missing packet is -being the SSRC present in the primary multicast RTP strea m- and a sequence number that is retrieved from the gap detected by the HNE D by inspecting the RTP payload header field of the unicast RTP burst packets carrying the original RTP sequence number (O S N), i.e. the corresponding RTP S N in the primary multicast session. When an FCC(/RET) client issues a RAMS-R for receiving a burst and AL-FEC is used to protect the LMB service, this burst contains only the RTP data without the AL-FEC parity packets. This is aligned with the LMB RET specification which forbids RET sessions on AL-FEC streams (Section F10 in [1]). When the LMB service and its associated AL FEC stream(s) are sent on different RTP SSM sessions (different transport address), it would require at least two dedicated RAMS interactions and at least two dedicated bursts in parallel. If this occurs, then the client needs to synchronise two different RAMs session which adds complexity to the client and the additional burst will cause significant bandwidth usage so compromising the speed of the channel change. DVB therefore does not allow FCC burst packet loss recovery by means of AL-FEC. 4.10 Retransmission session transport address and SSRC identifiers The following recommendations and rules apply for both DVB server-based FCC and LMB RET4 The SSRC used by the FCC(/LMB RET) server in the retransmission session comprising the burst shall be the same as the SSRC used by the head-end in the primary multicast session, as stipulated in RFC 4588. The SSRC identity used by the HNED in the retransmission session (and indicated in the field of the RTCP SDES, RR, Bye or RAMS-T messages exchanged with the Retransmission/Burst source entity ) may or 4 Note that these rules deviate from the rules specified in the RET specification in annex F of TS 102034 v1.4.1 , sections F4.2.2., F6.2.2 DVB BlueBook A152 12 may not be different from the SSRC identity it uses in primary multicast session (as indicated in the corresponding SSRC field of the RAMS-R, NACK, SDES, RR and Bye messages exchanged with the FT target). One can overcome typical NAT arrangements like "port restricted cone" and avoid opening an additional "pinhole" in the firewall for the RTP and RTCP packets transmitted by the FCC/(LMB RET) server in the retransmissions session when the following three rules are fulfilled: o The destination port/address of the RTP packets sent in the retransmission session have the same value as the source port/address of the RTCP FB RAMS-R (and NAC K, when DVB RET service is used) messages. o The source port/address of the RTP packets sent in the retransmission session have the same value as the destination port/address of the RTCP FB RAMS-R (and NAC K , when DVB RET service is used) messages. The latter is signaled to the HNED by means of the SD&S RTCPReporting@DestinationPort parameter. o The RTP and RTCP packets transmitted by the FCC(/LMB RET) server in the retransmission session are multiplexed on the same port as per [7]. When a system is deployed in the way as described above, the UDP destination port of RTCP packets issued by HNED in retransmission session shall be different from the destination port of the RTCP packets issued by the HNED in the primary multicast session. This is necessary to allow the FCC(/LMB RET) server to distinguish between RTCP messages received in the primary multicast RTP session and RTCP messages received in the RTP retransmission session. The UDP destination port of RTCP packets issued by HNED in retransmission session is signalled by means of the SD&S Retransmission_session @DestinationPortForRTCPReporting parameter.   In the case that the FCC(/LMB RET) server sends the RTP and RTCP packets in the RTP Retransmission session to the same destination transport address, the combination of the RTP Marker value and expected Payload Type value in the RTP packet header shall be different from the possible Packet Type values in the RTCP packets. This allows the HNED to distinguish between incoming RTP and RTCP packets in the retransmission session (see [7]). 4.11 RTSP and FCC Similar as for LMB and LMB RET, RTSP may be used for connection set-up prior to the RAMS-interaction for DVB server-based FCC . However there are a few subtle points: the core idea of the RAMS-interaction and RTP Burst is to accelerate the LMB acquisition process. Setting-up each RTP session by means of RTSP will delay again the LMB acquisition process, and hence reduces the FCC service value. as a single RTP retransmission session is used for LMB RET and FCC service, the required bandwidth for the RTP burst (at the start of the session) and the retransmission service (after the burst is terminated) are typically very different. There is no way to signal this and unless this highly variable bandwidth consumption is implicitly known to monitoring systems, care should be taken if RTSP is used mainly because of bandwidth monitoring/reservation purposes. It is therefore recommended to NOT use RTSP to set-up/tear down retransmission sessions when FCC service is used. As the RAMS-R is sent in the primary multicast session, and as any significant delay by which the RAMS- R can be sent to the FCC(/LMB RET) server will impact the FCC experience, it is also recommended to NOT use RTSP for setting-up/tearing down the primary multicast sessions for FCC-enabled LMB services. DVB BlueBook A152 13 4.12 QoS Priority settings The RTP packets in the retransmission session take over video bearer priority of corresponding RTP packets in the primary multicast session (which is DSCP 0b100010 or 0b100100). All RTCP packets have voice/video signaling priority setting (DSCP 0b11010). 4.13 FCC (/LMB RET) Service discovery The DVB configuration method for the FCC (/LMB RET) parameters is no different from what is defined for LMB RET. Via SD&S the FCC (/LMB RET) client is configured. The exception to this is the initial IP address of the FCC(/LMB RET) server(s) that can be configured in three different ways: 4.13.1 By means of DHCP FCC(/LMB Retransmission Server) Address option DHCP should be used at start up to get a list of IP addresses of FCC(/LMB RET) servers as described in 8.1.1.10. These IP addresses are the same for all LMB services. The servers shall be in the order of priority from first to last server to connect to. The method for connecting to the server and assuring its operation is vendor specific. 4.13.2 Via SD&S SD&S may also contain FCC(/LMB RET) server addresses which can be specified per LMB service. These addresses overrule the FCC(/LMB RET) server address obtained from DHCP for the specific LMB service where SD&S contains a server address value. 4.13.3 By means of RTCP RSI messages The Receiver Summary Information RTCP messages are defined in the annex F of the DVB handbook. The RSI messages with sub report block type equal to 0, 1 or 2 may be distributed over the SSM to signal the new address of an FCC(/LMB RET) server5. The FCC(/LMB RET) server address signaled in an RSI is only valid for a specific LMB service. The LMB RET server address signaled through RSI takes precedence over the FCC(/LMB RET) server address(es) that may be configured via SD&S for that specific service, and also takes precedence over the FCC(/LMB RET) server address(es) that may be configured via DHCP. Note that annex F specifies that the RSI can be sent either in the SSM of the primary multicast session, or in the SSM of the multicast LMB RET. If SD&S records are updated with new FCC(/LMB RET) server addresses after an RSI message signaling an FCC(/LMB RET) server address, then the new SD&S values for the FCC(/LMB RET) server will take preference over addresses in the RSI message. Note that FCC(/LMB RET) server addresses signaled via DHCP or RSI can be different for different access service regions as they can be distributed locally via the DHCP server or via the operational FCC(/LMB RET) server in the multicast LMB RET session (RSI message). 5 The RSI messages with sub report block type 0,1,2 signal the address and port of the Feedback Target logical entity (to which the RAMS-R and NACK messages are addressed). All other relevant FCC(/LMB RET) service parameter information is still retrieved from SD&S DVB BlueBook A152 14 4.14 SD&S FCC (/LMB RET) parameters overview A new set of parameters is defined for integration in the SD&S broadcast discovery records for DVB server- based FCC. The FCC parameters are grouped u Server-based LMB Enhancement Service the SD&S discovery records. When a LMB RET service is offered together with the server-based FCC for a specific LMB service, and an HNED makes use of both services, the HNED should ignore any SD&S signalled RET parameters defined in [1] when present, Server- based LMB Enhancement Service When an HNED makes use of RET services-only (and no server-based FCC ), it should retrieve and use the Server- based LMB Enhancement Service It is the responsibility of the service provider to make the values of the parameters consistent across the two Server-based LMB Enhancement Service in SD&S, and the service provider wants a RET-only enabled HNED and FCC(/RET)-enabled HNED to make use of the same parameter values. More specifically, the parameters that enable the configuration of an FCC (/LMB RET) client shall be listed in the SD&S broadcast discovery records under: /BroadcastDiscovery/ServiceList/SingleService/ServiceLocation/IPMulticastAddress/Server-based LMB Enhancement Service/ Service_Type6 This element indicates whether RET-only, FCC- eService/ServiceLocation/IPMulticastAddress/ Server-based LMB Enhancement Service 7 -based FCC (and for LMB RET with unicast-only repair when used in conjunction with server-based F C C) : RTCPReporting@DestinationAddress RTCPReporting@DestinationPort RTCPReporting@rtcp-bandwidth RTCPReporting@rtcp-rsize RTCPReporting@ trrint RTCPReporting@dvb-disablertcp-rr RTCPReporting@dvb-enable-bye RTCPReporting@dvb-rsi-mc-ret erviceList/SingleService/ServiceLocation/IPMulticastAddress/ Server-based LMB Enhancement Service /Retransmission_session 8 6 This service element is not defined in the RET-only SD&S in IPTV handbook v1.4.1 7 This set of elements and attributes for RET services-only is in IPTV handbook version 1.4.1 grouped under 8This set of elements and attributes for unicast RET services-only is in IPTV handbook version 1.4.1 grouped under DVB BlueBook A152 15 -based FCC (and for LMB RET with unicast-only repair when used in conjunction with server-based F C C) : Retransmission_session@SourcePort Retransmission_session@DestinationPort Retransmission_session@rtx-time Retransmission_session@rtcp-mux Retransmission_session @DestinationPortForRTCPReporting Retransmission_session@trr-int Retransmission_session@RTPPayloadTypeNumber Retransmission_session@RTSPControlURL The /BroadcastDiscovery/ServiceList/SingleService/ServiceLocation/IPMulticastAddress/ Server-based LMB Enhancement Service /Multicast_RET 9 / elements defined in annex F and in the SD&S section of the handbook are not relevant for server-based FCC, apart from the fact that when such a multicast packet loss repair service is enabled for LMB RET, this IP multicast may be used to transfer the RTCP RSI messages that are defined both for LMB RET and FCC service. When this is the case, this is signaled in RTCPReporting@dvb-rsi- mc-ret. 5 Server based FCC: SD&S broadcast discovery record parameters (Editor note: this section will be removed when server based F C C is integrated in the v1.5 of the DVB IPTV handbook, with subsequent update of the S D &S records in section 5) As explained in section 4.14, both the LMB RET-only records (defined in v1.4.1) and the new DVB server- based FCC records may be present in the SD&S that will be compliant with v1.5 of the DVB IPTV handbook. For an HNED that makes use of RET services only, the RET-only SD&S parameters as defined in the version 1.4 of the handbook [1] when present- take precedence over the new FCC/RET parameters that are defined in this section. An HNED that is FCC-enabled, shall use the new parameter set. The Table 1 describes the elements and attributes defined for FCC (/LMB RET) service in the SD&S broadcast discovery records. The table lists the name and definition of these parameters as specified in the IPTV handbook version 1.4 (LMB RET-only) (the two left columns), as well as the names and definitions of the new parameters valid in v1.5 for FCC(/RET) (two right columns). Name Definition for L M B R E T- Name Definition for F C C/ (L M B only (v1.4) R E T) (v1.5) (v1.4) (v1.5) (i.e. FCC-only OR LMB RET- (R E T-only) (F C C-only, F C C +R E T only OR FCC and RET and R E T-only) combined) Note: when blank, there is no change for the specific attribute name compared to v1.4 9This set of elements and attributes is in IPTV handbook version 1.4 grouped under /BroadcastDiscovery/ServiceList/SingleService/ServiceLocation/IPMulticastAddress/RTPRetransmission/MulticastRET DVB BlueBook A152 16 RTPRetransmission S ignals the use of RTP Signals the use of FCC/LMB /BroadcastDiscovery/Se Retransmission (RET) and rviceList/SingleService/S RET and the associated rviceList/SingleService/ the para meters associated erviceLocation/IPMultic parameters ServiceLocation/IPMult with retransm ission. astAddress/ Server-based icastAddress/RTPRetra LMB Enhancement NOTE: Parameters and nsmission NOTE: Para meters and attributes whose name starts attributes whose na me starts with "dvb" are defined in this with "dvb" are defined in specification, in Annex F. Other this specification, in Annex parameters and attributes are F . Other para meters and also defined within the relevant attributes are also defined references. within the relevant references. - - Defined Values: FCC, RET rviceList/SingleService/S erviceLocation/IPMultic Signals whether RET-only, astAddress/ Server-based FCC-only or FCC+RET LMB Enhancement services are provided RTCPReporting This element signals the This element signals the /BroadcastDiscovery/Se transport addresses and rviceList/SingleService/S transport addresses and rviceList/SingleService/ para meters associated with erviceLocation/IPMultic parameters associated with the ServiceLocation/IPMult the RTCP reporting in the astAddress/ Server-based RTCP reporting in the icastAddress/RTPRetra original MC RTP session. LMB Enhancement primary/original MC RTP nsmission/RTCPReport Service session. ing RTCPReporting@Desti List of IP addresses List of IP addresses (minimum 1 nationAddress (minimum 1 IP address) OR IP address) OR single DNS single DNS SRV RR. The IP SRV RR. The IP address address selected from this selected from this list by the list by the HNE D or resolved HNED or resolved by the by the HNE D, is used as the HNED, is the IP address of the IP Destination Address of FCC/LMB RET server . If more RTCP packets issued by than one IP address is provided, HNE D, i.e. IP address of then the client will attempt to RTCP target. At the sa me connect to each server in turn in time it is the IP Source the order presented until a address of the unicast RTP successful connection results RET packets. This address value may be overruled by an URL which is achieved either in-band (through RTCP RS I messages) or an URL that is obtained via D H CP. [Erratum: the above text mode, is indeed inside the definition field of this attribute in TS 102034 v1.4.1, but will be removed in v 1.5 because in DVB BlueBook A152 17 contradiction with section F.8] RTCPReporting@Desti U DP Destination Port of UDP Destination Port of RTCP nationPort RTCP packets issued by packets issued by HNED in the HNE D primary/original multicast session RTCPReporting@rtcp- Amount of bandwidth an Amount of bandwidth an HNED bandwidth HNE D may use for its RTCP may use for its RTCP reporting reporting (kb/s) in the (kb/s) in the primary/original primary/original MC session MC session . Default is 5% of . Default is 5% of RTP RTP stream bandwidth when strea m bandwidth when this this attribute is not present. attribute is not present. RTCPReporting@rtcp- Indicates that RTCP F B Indicates that RTCP FB rsize messages can be transmitted messages can be transmitted in in reduced size format, i.e. reduced size format. Default as stand-alone RTCP behaviour is that RTCP FB - messages are transmitted as compound RTCP reports. behaviour is that RTCP F B messages are transmitted as compound RTCP reports. RTCPReporting@ trrint Minimum period for Minimum period for compound compound RTCP reporting, RTCP reporting, in ms. Default in ms. Default value is zero value is zero when this attribute when this attribute is not is not present. present. RTCPReporting@dvb- Is present when HNED shall Is present when HNED shall disablertcp-rr disable RTCP RR reporting. disable RTCP RR reporting. Default RTCP RR is enabled Default RTCP RR is enabled when this attribute is not when this attribute is not present, i.e. that the default present, i.e. that the default value of this field is "false". value of this field is "false". RTCPReporting@dvb- When present, HNE D shall When present, HNED shall enable-bye issue BYE following rules as issue BYE following rules as described in annex F . described in annex F. Default Default BYE usage is BYE usage is disabled when disabled when this attribute this attribute is not present. is not present. BroadcastDiscovery/Se This element signals the BroadcastDiscovery/Serv This element signals the rviceList/SingleService/ transport addresses and iceList/SingleService/Ser transport addresses and ServiceLocation parameters associated with viceLocation/IPMulticast parameters associated with the the unicast RET session Address/ Server-based unicast retransmission session /IPMulticastAddress/R LMB Enhancement DVB BlueBook A152 18 TPRetransmission/Unic Service astRET /Retransmission_session UnicastRET@SourcePo U DP Source Port of unicast Retransmission_session UDP Source Port of unicast rt RTP RET packets. If not @SourcePort RTP retransmission session present, the port number in packets. If not present, the port these packets S HALL match number in these packets Server-based Reporting@ DestinationPort LMB Enhancement Service /RTCP UnicastRET@Destinati U DP Destination Port of Retransmission_session UDP Destination Port of onPort unicast RTP RET packets. If @ DestinationPort unicast RTP Retransmission not present, this port number session packets. If not present, matches the source port of this port number matches the the RTCP packets issued by source port of the RTCP packets the HNE D for RTCP issued by the HNED for RTCP reporting in the original reporting in the primary/original session. MC session. UnicastRET@rtx-time Amount of time (in Retransmission_session Amount of time (in milliseconds) an RTP packet @rtx-time milliseconds) an RTP packet payload is available for payload is available for retransmissions. retransmissions. UnicastRET@rtcp-mux If present, signals that RTCP Retransmission_session If present, signals that RTCP and RTP RET packets issued @rtcp-mux and RTP packets issued by by LMB RET server are FCC/LMB RET server in the multiplexed on the sa me retransmission session are destination port. If not multiplexed on the same present, then it follows destination port. If not present, standard definition, then it follows standard i.e., definition, i.e., Server-based icastRET@ Destination LMB Enhancement Service /retransmission_session@Destin UnicastRET@Destinati U DP destination port of Retransmission_session UDP destination port of RTCP onPortForRTCPReporti RTCP packets issued by @DestinationPortForRT packets issued by HNED in ng HNE D in RET session. If CPReporting retransmission session. If there this attribute is not present, is no server-based FCC service then RTCP RR on the RET deployed, then RTCP RR in the strea m shall be disabled by retransmission session shall be the HNE D disabled by the HNED when this attribute is not present. If a server-based FCC service is deployed, then RTCP RR may be issued by the HNED in the retransmission session. DVB BlueBook A152 19 UnicastRET@trr-int Minimum period for Retransmission_session Minimum period for compound compound RET RTCP @trr-int RTCP reporting in the reporting, in ms. Default retransmission session, in ms. value is zero when attribute Default value is zero when is not present. attribute is not present. UnicastRET@RTPPayl Dyna mic RTP payload type Retransmission_session Dynamic RTP payload type oadTypeNumber number of RET RTP packets. @RTPPayloadTypeNum number of RTP packets in ber retransmission session. UnicastRET@ssrc SSRC identifier value in This attribute is no longer unicast RET RTP packets. defined for F C C( and LMB Remark: will be RET) because SSRC identifier deprecated in v1.5! value of RTP packets in retransmission session shall match SSRC in primary/original multicast session. UnicastRET@RTSPCo The RTSP URL to be used Retransmission_session The RTSP URL that can be ntrolURL for controlling the unicast @RTSPControlURL used for controlling the unicast RET strea m. retransmission session. RTCPReporting@dvb- Signals that the RSI packets Signals that the RSI packets of rsi-mc-ret of the original MC RTP the primary/ original MC RTP session are distributed in the session are distributed in the MC RET session. MC RET session. T able 1 SD &S attributes and elements for L M B R E T -only (v1.4 of the IP T V handbook) and server-based F C C/L M B R E T (v1.5 of the D V B IP T V handbook) The Table 2 lists the elements defined for LMB RET with unicast repair that are not defined for server based FCC, but their meaning is-where needed- slightly modified for LMB RET services combined with FCC (without losing backward compliancy):   Name Definition for LMB Definition for LMB RET only (v1.4) RET(/FCC) (i.e. LMB RET-only or FCC and LMB RET combined) (v1.5) RTCPReporting@dvb- Minimum time a Minimum time a t-ret receiver should wait for receiver should wait for a requested RET packet a requested RET packet (per retransmission (per retransmission request/attempt) before request/attempt) before issuing another issuing another retransmission request retransmission request DVB BlueBook A152 20 for the same packet(s). for the same packet(s). This time period has as This time period has as starting point the starting point the sending of the RTCP sending of the RTCP FB message, and is FB NACK message, expressed in and is expressed in milliseconds. If not milliseconds. If not present, it is up to the present, it is up to the HNED to choose an HNED to choose an appropriate delay time appropriate delay time with which failed with which failed retransmissions are re- retransmissions are re- attempted. attempted. RTCPReporting@dvb- Upon packet loss Upon packet loss t-wait-min detection, the HNED detection, the HNED shall issue an RTCP shall issue an RTCP FB message in an FB NACK message in interval randomly an interval randomly chosen between dvb-t- chosen between dvb-t- waitmin and dvb-t- wait-min and dvb-t- wait-max (both wait-max (both expressed in ms). expressed in ms). Default value for dvb-t- Default value for dvb-t- wait-min is 0 ms. wait-min is 0 ms. RTCPReporting@dvb- Upon packet loss Upon packet loss t-wait-max detection, the HNED detection, the HNED shall issue an RTCP shall issue an RTCP FB message in an FB NACK message in interval randomly an interval randomly chosen between dvb-t- chosen between dvb-t- waitmin and dvb-t- wait-min and dvb-t- wait-max (both wait-max (both expressed in ms). expressed in ms). Default value for dvb-t- Default value for dvb-t- wait-max is 0 ms. wait-max is 0 ms. RTCPReporting@dvb- Contains a 32-bit wide Contains a 32-bit wide ssrc-bitmask bitmask. Those HNED bitmask. Those HNED s for which their SSRC s for which their SSRC match the SSRC inside match the SSRC inside the original MC the original MC streams on the bit streams on the bit positions that are set to positions that are set to 1 in the bitmask, shall 1 in the bitmask, shall set both dvbt-wait-min set both dvbt-wait-min and dvb-t-wait-max to and dvb-t-wait-max to zero, overruling the zero, overruling the signaled values dvb-t- signaled values dvb-t- wait-min and dvb-t- wait-min and dvb-t- wait-max. Default all wait-max. Default all bit positions in the bit positions in the bitmask are 1, meaning bitmask are 1, meaning that the dvb-t-wait-min that the dvb-t-wait-min and dvb-t-wait-max are and dvb-t-wait-max are not overruled. not overruled. RTCPReporting@dvb- SSRC of upstream SSRC of upstream ssrc-upstreamclient client for which LMB client for which LMB server translates RTCP R E T (/F C C)server DVB BlueBook A152 21 FB message into RTCP translates RTCP FB FF message. N A C K message into RTCP FF message. T able 2 A ttributes/E lements that apply to L M B R E T -only     (A subset of) the elements/attributes defined for IP multicast RET are only relevant for the FCC service when the RSI RTCP messages are distributed in this IP multicast (signaled by RTCPReporting@dvb-rsi-mc-ret). Their names and meaning remain unmodified compared to v1.4 of the handbook. In v1.5 these optional attributes are grouped in the SD&S broadcast discovery records under /BroadcastDiscovery/ServiceList/SingleService/ServiceLocation/IPMulticastAddress/ Server-based LMB Enhancement Service /Multicast_RET For SD&S compliant to v1.4.1 they are grouped under: /BroadcastDiscovery/ServiceList/SingleService/ServiceLocation/IPMulticastAddress/RTPRetransmission/Multi castRET DVB BlueBook A152 22