idnits 2.17.1 draft-ietf-avtext-splicing-notification-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6828]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: When the mixer intercepts the RTCP splicing notification message, it MAY NOT forward the message to the receivers in order to reduce RTCP bandwidth consumption or to avoid downstream receivers from detecting splicing defined in Section 4.5 in [RFC6828]. -- The document date (July 29, 2014) is 3558 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SRTP-ENCR-HDR' is mentioned on line 400, but not defined == Unused Reference: 'RFC4566' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'RFC6904' is defined on line 488, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) ** Downref: Normative reference to an Informational RFC: RFC 6828 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTEXT Working Group J. Xia 3 INTERNET-DRAFT R. Even 4 Intended Status: Standards Track R. Huang 5 Expires: January 30, 2015 Huawei 6 L. Deng 7 China Mobile 8 July 29, 2014 10 RTP/RTCP Extension for RTP Splicing Notification 11 draft-ietf-avtext-splicing-notification-00 13 Abstract 15 Content splicing is a process that replaces the content of a main 16 multimedia stream with other multimedia content, and delivers the 17 substitutive multimedia content to the receivers for a period of 18 time. The RTP mixer is designed to handle RTP splicing in [RFC6828], 19 but how the RTP mixer knows when to start and end the splicing is 20 still unspecified. 22 This memo defines two RTP/RTCP extensions to indicate the splicing 23 related information to the RTP mixer: an RTP header extension that 24 conveys the information in-band and an RTCP packet that conveys the 25 information out-of-band. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2 Overview of RTP Splicing Notification . . . . . . . . . . . . . 4 68 3 Conveying Splicing Interval in RTP/RTCP extensions . . . . . . 5 69 3.1 RTP Header Extention . . . . . . . . . . . . . . . . . . . . 5 70 3.2 RTCP Splicing Notification Message . . . . . . . . . . . . . 6 71 4 Reduing Splicing Latency . . . . . . . . . . . . . . . . . . . 7 72 5 Failure Cases . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 6 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 75 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 76 8.1 RTCP Control Packet Types . . . . . . . . . . . . . . . . . 9 77 8.2 RTP Compact Header Extensions . . . . . . . . . . . . . . . 10 78 9 Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 10.1 Normative References . . . . . . . . . . . . . . . . . . . 10 81 10.2 Informative References . . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 84 1 Introduction 86 Splicing is a process that replaces some multimedia content with 87 other multimedia content and delivers the substitutive multimedia 88 content to the receivers for a period of time. In some predictable 89 splicing cases, e.g., advertisement insertion, the splicing duration 90 MUST be inside of the specific, pre-designated time slot. Certain 91 timing information about when to start and end the splicing must be 92 first acquired by the mixer to start the splicing. This document 93 refers to this information as Splicing Interval. 95 [SCTE35] provides a method that encapsulates the Splicing Interval 96 inside the MPEG2-TS layer in cable TV systems. But in RTP splicing 97 scenario described in [RFC6828], the mixer has to decode the RTP 98 packets, search and solve the Splicing Interval inside the payloads. 99 The need for such processing enhances the workload of the mixer and 100 limits the size of RTP sessions the mixer can support. 102 The document defines an RTP header extension [RFC5285] through which 103 the main RTP sender can provide the Splicing Interval by including it 104 in the RTP packets. 106 Nevertheless, the Splicing Interval conveyed in the RTP header 107 extension might not reach the mixer successfully, any splicing un- 108 aware middlebox on the path between the RTP sender and the mixer 109 might strip the RTP header extension. 111 To increase robustness against above case, the document also defines 112 a new RTCP packet type in a complementary fashion to carry the 113 Splicing Interval to the mixer even though RTCP is inherently 114 unreliable too. 116 1.1 Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 Most terminology defined in "Content Splicing for RTP Sessions" 123 [RFC6828] applies to this document except the following one. 125 Splicing Interval: 127 A set of certain metadata that allows the mixer to know when to 128 start and end the RTP splicing. The information consists of a 129 couple of NTP-format timestamps on the splicing in point and on 130 the splicing out point. 132 2 Overview of RTP Splicing Notification 134 According to RTP Splicing draft [RFC6828], a mixer is designed to do 135 splicing on the RTP layer, but it cannot insert the substitutive 136 content randomly but only do that at the reserved time slots set by 137 the main RTP sender. This implies the mixer must first know the 138 Splicing Interval from the main RTP sender before splicing starts. 140 When a new splicing is forthcoming, the main RTP sender MUST send the 141 Splicing Interval to the mixer. Usually, the Splicing Interval SHOULD 142 be sent more than once to against the possible packet loss. To enable 143 the mixer to get the substitutive content before the splicing starts, 144 the main RTP sender MUST send the Splicing Interval far enough in 145 advance. Alternatively, the main RTP sender can estimate when to send 146 the Splicing Interval based on the round-trip time (RTT) following 147 the mechanisms in section 6.4.1 of [RFC3550] when the mixer sends 148 RTCP RR to the main sender. 150 The substitutive sender also needs to learn the Splicing Interval 151 from the main RTP sender in advance, and thus estimates when to 152 transfer the substitutive content to the mixer. The Splicing Interval 153 could be transmitted from the main RTP sender to the substitutive 154 content using some out-of-band mechanisms, the details how to achieve 155 that are beyond the scope of this memo. To ensure the Splicing 156 Interval is valid to the main RTP sender and the substitutive RTP 157 sender, the two senders MUST share a common reference clock, so the 158 mixer can achieve accurate splicing. 160 In this document, the main RTP sender uses a couple of NTP-format 161 timestamps, derived from the common reference clock, to indicate when 162 to start and end the splicing to the mixer: the timestamp of the 163 first substitutive RTP packet on the splicing in point, and the 164 timestamp of the first main RTP packet on the splicing out point. 166 When the substitutive RTP sender gets the Splicing Interval, it must 167 prepare the substitutive stream. The RTP timestamp of the first 168 substitutive RTP packet that would be presented on the receivers MUST 169 correspond to the same time instant as the former NTP timestamp in 170 the Splicing Interval. To enable mixer to know the first substitutive 171 RTP packet it begins to output, the substitutive RTP sender MUST 172 enable the mixer to know above RTP timestamp in advance, e.g., from 173 prior receipt of RTCP SR message. 175 When the splicing will end, the RTP timestamp of the first main RTP 176 packet that would be presented on the receivers MUST correspond to 177 the same time instant as the latter NTP timestamp in the Splicing 178 Interval. 180 3 Conveying Splicing Interval in RTP/RTCP extensions 182 This memo defines two backwards compatible RTP extensions to convey 183 the Splicing Interval to the mixer: an RTP header extension and an 184 RTCP splicing notification message. 186 3.1 RTP Header Extention 188 The RTP header extension mechanism defined in [RFC5285] can be 189 adapted to carry the Splicing Interval consisting of a couple of NTP- 190 format timestamps. 192 One variant is defined for this header extension. It carries the 7 193 octets splicing-out NTP timestamp (lower 24-bit part of the Seconds 194 of a NTP-format timestamp and the 32 bits of the Fraction of a NTP- 195 format timestamp as defined in [RFC5905]), followed by the 8 octets 196 splicing-in NTP timestamp (64-bit NTP-format timestamp as defined in 197 [RFC5905]). The top 8 bits of the splicing-out NTP timestamp are 198 referred from the top 8 bits of the splicing-in NTP timestamp, under 199 the consumption that the splicing-out time is after the splicing-in 200 time, and the splicing interval is less than 2^25 seconds, this order 201 allows full resolution for splicing-in NTP timestamp while keeping 4 202 octets alignment. 204 The format is shown in Figures 1. 206 0 1 2 3 207 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | 0xBE | 0xDE | length=4 | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E 211 | ID | L=15 | OUT NTP timestamp format - Seconds (bit 8-31) |x 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t 213 | OUT NTP timestamp format - Fraction (bit 0-31) |e 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n 215 | IN NTP timestamp format - Seconds (bit 0-31) |s 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i 217 | IN NTP timestamp format - Fraction (bit 0-31) |o 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n 220 Figure 1: Sample hybrid NTP Encoding Using 221 the One-Byte Header Format 223 Note that the inclusion of an RTP header extension will reduce the 224 efficiency of RTP header compression. It is RECOMMENDED that the main 225 sender begins to insert the RTP header extensions into a number of 226 RTP packets in advance of the splicing starting, while leaving the 227 remain RTP packets unmarked. 229 After the mixer intercepts the RTP header extension and derives the 230 Splicing Interval, it will generate its own stream and could not 231 include the RTP header extension in outgoing packets to reduce header 232 overhead. 234 Furthermore, whether the in-band NTP-format timestamps are included 235 or not, RTCP splicing notification message in next section MUST be 236 sent to provide robustness in the case of any splicing-unaware 237 middlebox that might strip RTP header extensions. 239 3.2 RTCP Splicing Notification Message 241 Besides the RTP header extension, the main RTP sender includes the 242 Splicing Interval in an RTCP splicing notification message. 244 The RTCP splicing notification message is a new RTCP packet type. It 245 has a fix header followed by a couple of NTP-format timestamps: 247 0 1 2 3 248 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 |V=2|P|reserved | PT=TBA | length | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | SSRC | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | IN NTP Timestamp (most significant word) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | IN NTP Timestamp (least significant word) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | OUT NTP Timestamp (most significant word) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | OUT NTP Timestamp (least significant word) | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 2: RTCP Splicing Notification Message 265 The RSI packet includes the following fields: 267 Length: 16 bits 269 As defined in [RFC3550], the length of the RTCP packet in 32-bit 270 words minus one, including the header and any padding. 272 SSRC: 32 bits 273 The SSRC of the Main RTP Sender. 275 Timestamp: 64 bits 277 Indicates the wallclock time when this splicing starts and ends. 278 The full-resolution NTP timestamp is used, which is a 64-bit, 279 unsigned, fixed-point number with the integer part in the first 32 280 bits and the fractional part in the last 32 bits. This format is 281 similar to RTCP Sender Report (Section 6.4.1 of [RFC3550]). 283 The RTCP splicing notification message can be appended to RTCP SR the 284 main RTP sender generates in compound RTCP packets, and hence follows 285 the compound RTCP rules defined in Section 6.1 in [RFC3550]. 287 If the use of non-compound RTCP [RFC5506] was previously negotiated 288 between the sender and the mixer, the RTCP splicing notification 289 message may be sent as non-compound RTCP packets. 291 When the mixer intercepts the RTCP splicing notification message, it 292 MAY NOT forward the message to the receivers in order to reduce RTCP 293 bandwidth consumption or to avoid downstream receivers from detecting 294 splicing defined in Section 4.5 in [RFC6828]. 296 4 Reduing Splicing Latency 298 When splicing starts or ends, the mixer outputs the multimedia 299 content from another sender to the receivers. Given that the 300 receivers must first acquire certain information ([RFC6285] refers to 301 this information as Reference Information) to start processing the 302 multimedia data, either the main RTP sender or the substitutive 303 sender SHOULD provide the Reference Information align with its 304 multimedia content to reduce the delay caused by acquiring the 305 Reference Information. The means by which the Reference Information 306 is distributed to the receivers is out of scope of this memo. 308 Another latency element is synchronization caused delay. The 309 receivers must receive enough synchronization metadata prior to 310 synchronizing the separate components of the multimedia streams when 311 splicing starts or ends. Either the main RTP sender or the 312 substitutive sender SHOULD send the synchronization metadata early 313 enough so that the receivers can play out the multimedia in a 314 synchronized fashion. The mechanisms defined in [RFC6051] are 315 RECOMMENDED to be adopted to reduce the possible synchronization 316 delay. 318 5 Failure Cases 319 This section examines the implications of losing RTCP splicing 320 notification message and other failure case, e.g., the RTP header 321 extension is stripped on the path. 323 Given there may be splicing un-aware middlebox on the path between 324 the main RTP sender and the mixer, one heuristics will be used to 325 verify whether or not the Splicing Interval reaches the mixers. 327 If the mixer does not get the Splicing Interval when the splicing 328 starts, it will still output the main content to the downstream 329 receivers and forward the RTCP RR packets sent from downstream 330 receivers to the main RTP sender. In such case, the main RTP sender 331 can learn the splicing failed. 333 In a similar manner, the substitutive sender can learn the splicing 334 failed if it does not receive any RTCP RR packets from downstream 335 receivers when the splicing starts. 337 Upon the detection of a failure, the main RTP sender or the 338 substitutive sender SHOULD check the path to the failed mixer, or 339 fallback to the payload specific mechanisms, e.g., MPEG-TS splicing 340 solution defined in [SCTE35]. 342 6 SDP Signaling 344 This document defines the URI for declaring this header extension in 345 an extmap attribute to be "urn:ietf:params:rtp-hdrext:splicing- 346 interval". 348 This document also reuses the Flow Identification (FID) semantics 349 defined in SDP Grouping Framework [RFC5888] to represent the 350 relationship between the main RTP stream and the substitutive RTP 351 stream. 353 The next example shows how the "group" attribute used with FID 354 semantics can indicate RTP splicing support on RTP sender. 356 v=0 357 o=xia 1122334455 1122334466 IN IP4 splicing.example.com 358 s=RTP Splicing Example 359 t=0 0 360 a=group:FID 1 2 361 m=video 30000 RTP/AVP 100 362 i=Main RTP Stream 363 c=IN IP4 233.252.0.1/127 364 a=rtpmap:100 MP2T/90000 365 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 366 a=mid: 1 367 m= video 30001 RTP/AVP 100 368 i=Substitutive RTP Stream 369 c=IN IP4 233.252.0.2/127 370 a=sendonly 371 a=mid: 2 373 Figure 3: Example SDP for a single-channel splicing scenario 375 The mixer receiving the SDP message above receives one MPEG2-TS 376 stream (payload 100) from the main RTP sender (with multicast 377 destination address of 233.252.0.1) on port 30000, and/or receives 378 another MPEG2-TS stream from the substitutive RTP sender (with 379 multicast destination address of 233.252.0.2) on port 30001. But at 380 a particular point in time, the mixer only selects one stream and 381 output the content from the chosen stream to the downstream 382 receivers. 384 7 Security Considerations 386 The security considerations of the RTP specification [RFC3550], the 387 general mechanism for RTP header extensions [RFC5285] and the 388 security considerations of the RTP splicing specification [RFC6828] 389 apply. 391 The RTP header extension defined in Section 4.1 include two NTP- 392 format timestamps. In the Secure Real-time Transport Protocol 393 (SRTP)[RFC3711], RTP header extensions are authenticated but not 394 encrypted. A malicious endpoint could choose to set the values in 395 this header extension falsely, so as to falsely claim the splicing 396 time. 398 In scenarios where this is a concern, additional mechanisms MUST be 399 used to protect the confidentiality of the header extension. This 400 mechanism could be header extension encryption [SRTP-ENCR-HDR], or a 401 lower-level security and authentication mechanism such as IPsec 402 [RFC4301]. 404 8 IANA Considerations 406 8.1 RTCP Control Packet Types 408 Based on the guidelines suggested in [RFC5226], a new RTCP packet 409 format has been registered with the RTCP Control Packet Type (PT) 410 Registry: 412 Name: SNM 414 Long name: Splicing Notification Message 416 Value: TBA 418 Reference: This document 420 8.2 RTP Compact Header Extensions 422 The IANA has also registered a new RTP Compact Header Extension 423 [RFC5285], according to the following: 425 Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval 427 Description: Splicing Interval 429 Contact: Jinwei Xia 431 Reference: This document 433 9 Acknowledges 435 TBD 437 10 References 439 10.1 Normative References 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, March 1997. 444 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 445 Jacobson, "RTP: A Transport Protocol for Real-Time 446 Applications", STD 64, RFC 3550, July 2003. 448 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 449 Description Protocol", RFC 4566, July 2006. 451 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 452 Header Extensions", RFC 5285, July 2008. 454 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 455 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 457 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 458 "Network Time Protocol Version 4: Protocol and Algorithms 459 Specification", RFC 5905, June 2010. 461 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 462 Flows", RFC 6051, November 2010. 464 [RFC6828] Xia, J., "Content Splicing for RTP Sessions", RFC 6828, 465 January 2013. 467 10.2 Informative References 469 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 470 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 471 RFC 3711, March 2004. 473 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 474 Internet Protocol", RFC 4301, December 2005. 476 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 477 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 478 May 2008. 480 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 481 Real-Time Transport Control Protocol (RTCP): Opportunities 482 and Consequences", RFC 5506, April 2009. 484 [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, 485 "Unicast-Based Rapid Acquisition of Multicast RTP 486 Sessions", RFC 6285, June 2011. 488 [RFC6904] Lennox, J.,"Encryption of Header Extensions in the Secure 489 Real-Time Transport Protocol (SRTP)", April 2013. 491 [SCTE35] Society of Cable Telecommunications Engineers (SCTE), 492 "Digital Program Insertion Cueing Message for Cable", 493 2011. 495 Authors' Addresses 497 Jinwei Xia 498 Huawei 500 Email: xiajinwei@huawei.com 501 Roni Even 502 Huawei 504 Email: ron.even.tlv@gmail.com 506 Rachel Huang 507 Huawei 509 Email: rachel.huang@huawei.com 511 Lingli Deng 512 China Mobile 514 Email: denglingli@chinamobile.com