WO2008119268A1 - Procédé, dispositif et système d'émission et de réception d'informations de message - Google Patents

Procédé, dispositif et système d'émission et de réception d'informations de message Download PDF

Info

Publication number
WO2008119268A1
WO2008119268A1 PCT/CN2008/070088 CN2008070088W WO2008119268A1 WO 2008119268 A1 WO2008119268 A1 WO 2008119268A1 CN 2008070088 W CN2008070088 W CN 2008070088W WO 2008119268 A1 WO2008119268 A1 WO 2008119268A1
Authority
WO
WIPO (PCT)
Prior art keywords
notification message
rtp
packet
rtcp packet
rtcp
Prior art date
Application number
PCT/CN2008/070088
Other languages
English (en)
French (fr)
Inventor
Peiyu Le
Teng Shi
Jie Zhang
Li Chen
Xin Fu
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to EP08700107A priority Critical patent/EP2026531A4/en
Publication of WO2008119268A1 publication Critical patent/WO2008119268A1/zh
Priority to US12/346,013 priority patent/US20090110006A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/18—Arrangements for synchronising broadcast or distribution via plural systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/53—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers
    • H04H20/59—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers for emergency or urgency

Definitions

  • the present invention relates to communication technologies, and in particular, to a method, device, and system for transmitting and receiving a notification message.
  • BACKGROUND With the rapid development of the Internet, a large number of multimedia services have been widely used, such as mobile video, television broadcasting, video conferencing, online education, interactive games, and the like.
  • wireless communication systems supporting the multimedia service application, including terrestrial broadcasting technology-based wireless communication systems, such as Digital Video Broadcasting-Handheld (“DVB-H”) system in Europe, and terrestrial digital data in Korea.
  • Multimedia broadcasting Terrestrial-Digital Multimedia Broadcasting, referred to as "T-DMB”
  • T-DMB Satellite Digital Multimedia Broadcasting
  • SDMB Satellite Digital Multimedia Broadcasting
  • MBMS Multimedia Broadcast/Multicast Service
  • BCMCS Broadcast Multicast Multicast Service
  • the wireless communication system includes: a server, configured to generate and deliver a real-time transport protocol/real-time transport control protocol (RTP/RTCP) packet, a notification message, and a terminal, configured to receive an RTP/RTCP packet and a notification message delivered by the server And process the RTP/RTCP packet according to the notification message.
  • a server configured to generate and deliver a real-time transport protocol/real-time transport control protocol (RTP/RTCP) packet, a notification message
  • RTP/RTCP real-time transport protocol/real-time transport control protocol
  • the notification message refers to a message sent by an operator to a user or a terminal in a mobile broadcast system when certain events (such as an emergency emergency, a system failure event, a program content introduction event, a software update event, etc.) occur.
  • certain events such as an emergency emergency, a system failure event, a program content introduction event, a software update event, etc.
  • the user terminal performs corresponding processing.
  • Its There is a notification message related to the program, for example, when the user watches the program, the prize question and question sent in a certain key episode, or the subtitle related to the program, the content of the notification message needs to be synchronized with the program content to reflect the notification message. The meaning.
  • the existing notification message is in the format of XML text.
  • the message format is as follows:
  • Embodiments of the present invention provide a method, apparatus, and system for transmitting and receiving a notification message for resolving a problem that a notification message cannot be accurately synchronized with a program stream.
  • An embodiment of the present invention provides a method for sending a notification message, including:
  • the embodiment of the invention further discloses a method for receiving a notification message, which includes:
  • the embodiment of the invention further discloses a device for sending a notification message, comprising:
  • Obtaining a module configured to obtain a notification message synchronized with the program, and obtain a synchronization time stamp synchronized with the program;
  • An RTP/RTCP packet encapsulating module configured to encapsulate the notification message into an RTP/RTCP packet corresponding to the synchronization timestamp obtained by the obtaining module;
  • a sending module configured to send the RTP/RTCP packet obtained by the RTP/RTCP packet encapsulation module.
  • the embodiment of the invention further discloses a device for receiving a notification message, comprising:
  • a receiving module configured to receive an RTP/RTCP packet sent by the sending notification message device
  • the RTP/RTCP packet decapsulation module is configured to decapsulate the RTP/RTCP packet received by the receiving module to obtain a notification message, and process the notification message according to the format of the notification message.
  • the embodiment of the invention further discloses a system for transmitting a notification message, comprising:
  • a message source entity configured to generate a notification message synchronized with the program and a synchronization time stamp synchronized with the program, and send the notification message and the synchronization time stamp to the sending notification message device;
  • Sending a notification message device configured to obtain a notification message synchronized with the program generated by the message source entity and a synchronization timestamp synchronized with the program, and encapsulate the notification message in an RTP/RTCP packet corresponding to the synchronization timestamp
  • the RTP/RTCP packet is sent to the receiving notification message device.
  • Embodiments of the present invention enable the notification message to be accurately synchronized with the program stream by carrying a notification message in the RTP/RTCP packet.
  • FIG. 1 shows a flow of transmitting a notification message according to an embodiment of the present invention
  • FIG. 2 shows a flow of decapsulating an RTP/RTCP packet to obtain a notification message according to an embodiment of the present invention
  • FIG. 3 shows a flow of decapsulating an RTP/RTCP packet to obtain a notification message according to Embodiment 2 of the present invention
  • FIG. 4 is a flowchart showing a process of decapsulating an RTP/RTCP packet to obtain a notification message according to Embodiment 3 of the present invention
  • the fourth embodiment of the present invention decapsulates the RTP/RTCP packet to obtain a notification message.
  • FIG. 6 shows a system for transmitting a notification message according to Embodiment 5 of the present invention.
  • an embodiment of the present invention provides a method for transmitting a notification message, including: Step 1: Obtain a notification message synchronized with a program, and obtain a synchronization time stamp synchronized with the program. Step 2. Encapsulate the notification message into an RTP/RTCP packet corresponding to the synchronization timestamp. Step 3: Send the RTP/RTCP packet to the user terminal.
  • Step 4 The user terminal decapsulates the RTP/RTCP packet to obtain a notification message.
  • steps 2 and 4 in order to encapsulate the notification message into the RTP/RTCP packet corresponding to the synchronization timestamp, according to an embodiment of the present invention, it is first necessary to extend the format of the RTP/RTCP packet, and then encapsulate the notification message into In the RTP/RTCP package.
  • the method for extending the RTP/RTCP packet format, the corresponding method for encapsulating the notification message into the RTP/RTCP packet, and the corresponding decapsulation of the RTP/RTCP packet to obtain the notification are introduced. The method of the message.
  • This embodiment describes a method of extending an RTP header, encapsulating a notification message in an RTP header, and decapsulating an RTP header to obtain a notification message.
  • the extension field of the RTP header is expanded, and the extension field includes: a "defined by profile” field, a length (length), and a header extension (extension header). Take the type definition field in the extension field as the notification message flag field.
  • the notification flag field is set to valid (such as set to "0xC051"), it indicates that the packet header of the RTP packet contains a notification message. Otherwise, the packet header of the RTP packet does not contain a notification message; the header extension field of the extension field is added.
  • the format of the RTP header is as follows:
  • CSRC Convergent source
  • V version, 2bits, used to identify the version of the RTP protocol used.
  • the current RTP version is 2;
  • P padding, lbit, if set to 1, there is one or more padding bytes at the end of the payload.
  • the last padding byte identifies the total number of padding bytes (including the last byte).
  • CSRC count 4bits, identifies the number of CSRCs for this stream. Its number determines the size of the RTP header.
  • M marker, lbit, the meaning of this field varies according to the profile, which is determined by the Profile.
  • the Profile can also not use this field, but put the marker field into the payload.
  • PT payload type
  • ayload type 7bits, used to identify the data carried in the RTP payload. Why format. The terminal parses the payload accordingly.
  • Reference Sequence number 16bits, serial number, identifies the order of the RTP packets. In an RTP session, the sequence number of the RTP packet is incremented. The starting sequence number of the RTP packet must be random.
  • Timestamp 32bits, timestamp, identifies the time of the first byte in the RTP packet.
  • the terminal can correctly recover the original media stream by using the timestamp. Timestamp can also be used to synchronize multiple Media stream, See the 5.4 section for the synchronization mechanism of timestamp.
  • notification message flag field when the notification message flag field is set to valid
  • Extension header The field that carries the notification message.
  • the extension header of the header extension field can set multiple notification messages, as shown in the parameters of each notification message:
  • the message source After the notification message flag field and the field carrying the notification message are determined, the message source generates a notification message payload synchronized with the program according to the program content, and determines parameter information such as a synchronization timestamp, a notification message identifier, and a notification message subtype. And encapsulating the notification message payload and the notification message identifier, the notification message subtype, and the like into the RTP header corresponding to the synchronization timestamp. Then the RTP header Send to the terminal along with the program.
  • parameter information such as a synchronization timestamp, a notification message identifier, and a notification message subtype.
  • the terminal listens to the IP address and port number of the RTP packet to obtain the RTP packet. As shown in FIG. 2, the following describes decapsulating the RTP packet to obtain a notification message.
  • Step 201 Obtain an RTP packet according to the PT, that is, the terminal parses the RTP packet header to determine whether there is an extension header.
  • Step 202 Determine whether there is an extension header. If yes, go to step 203, otherwise go to step 208. That is, through the "X" field in the RTP header (see the RTP header description part in this embodiment) to determine whether there is an extension header, if the "X" field is 1, it indicates that there is an extension header, if the "X” field is 0, indicating no extension header.
  • Step 203 Determine whether a notification message exists according to the defined profile field of the extension header. If yes, perform step 204, otherwise perform step 208.
  • the notification flag field indicates that the notification message exists (for example, set to "0xC051"
  • Step 204 Obtain a notification message from an extended header extension header of the RTP header.
  • Step 205 The terminal performs pre-processing on each notification message according to the defined message format, and determines whether to process the notification message according to the pre-processing result. If yes, step 207 is performed; otherwise, step 206 is performed.
  • the pre-processing includes: determining, according to the ID of the notification message, whether the message has been received; determining whether it is necessary to receive according to the subtype of the notification message; determining the priority of the message, determining whether immediate processing is required; determining according to the version information of the message Whether it is necessary to update the existing message; according to the Valid to time, determine whether the message is expired; according to the provider ID of the notification message, determine whether the user cares about the message, whether the message needs to be processed, and the like.
  • Step 206 discarding the message, and then performing step 208.
  • Step 207 The terminal decompresses the payload of the Length indicating length according to the compression manner of the notification message.
  • the notification message is synchronized with the program according to the synchronization time stamp, and the decompressed payload content is processed.
  • the notification message is accurately synchronized with the program stream by setting the notification message in the extension header of the RTP packet with which the time stamp is synchronized. Since the notification message uses the same RTP packet as the program stream, the terminal only needs to listen to the address and port number where the program is located.
  • This embodiment describes a method of extending an RTCP SR (RTCP Transmit Report) packet, encapsulating a notification message in an RTCP SR packet, and decapsulating an RTCP SR packet to obtain a notification message.
  • RTCP SR RTCP Transmit Report
  • the RTCP SR package structure is as follows:
  • RC Reception report Count
  • the identifier contains the number of reports received
  • PT Pack Type, taking 200 for the RTCP SR packet
  • Sender information Sender information.
  • NTP timestamp Send this NTP sample time for sending a report
  • RTP timestamp The RTP sample time when this report was sent.
  • the RTP sample time here is the same as the sample time in the RTP session.
  • sender's packet count The number of all RTP packets sent by the sender from the time the transmission is sent to the current time (NTP). If the sender's SSRC changes, this value needs to be reset.
  • Type specifies the extension. As specified in the RTP/RTCP protocol, this field is defined by the profile.
  • the type extension field is extended to transmit a notification message, which includes the following parameters: Parameter name Parameter description type The type of information carried by the extension, which needs to be identified as a notification message.
  • Notification message ID The ID of the notification message
  • Subtype of subtype notification message which can be used to filter notification messages
  • Version information Version information compress type
  • the compression mode of the notification message such as 0x00 is uncompressed, 0x01 is Bim compression, 0x02 is Gzip compression, etc.
  • Notification message payload The content of the notification message, where type is used to identify whether the notification message is carried in the type specified extension field, that is, when type is set to valid (if set to: 0x0001), the type designation is specified.
  • the extension field carries the notification message, otherwise it indicates that the type specification extension field does not carry the notification message.
  • the contents of other fields are the parameters of the notification message and the content of the notification message.
  • the type specifies the content of the extension field. It can be specifically:
  • the notification message may be encapsulated into the RTCP SR packet, and the method of the device is as follows:
  • the message source generates a notification message payload synchronized with the program according to the program content, and determines parameter information such as a synchronization time stamp, a notification message ID, and a notification message subtype.
  • the notification message payload, and the parameters of the notification message ID, the notification message subtype, and the like are encapsulated into the type specification extension field of the RTCP SR packet corresponding to the synchronization time stamp.
  • the terminal accesses the RTCP SR packet to obtain a notification message.
  • the following describes the process of decapsulating the RTCP SR packet to obtain a notification message.
  • Step 302 Obtain synchronization information with the RTP carrying the program stream according to the NTP timestamp and the RTP time stamp.
  • Step 303 Obtain receiving information about the program source SSRC-n.
  • Step 304 The terminal determines whether the obtained RTCP SR packet includes the type specified extension field according to whether the length exceeds a predetermined value. If yes, step 305 is performed; otherwise, step 308 is performed.
  • Step 305 The terminal specifies the type parameter of the extended field according to the type, and determines whether the notification message is carried in the type specified extension field. If yes, go to step 306; otherwise, go to step 308.
  • Step 306 The terminal performs pre-processing according to the format of the type-specified extension field, and determines whether to process the notification message according to the pre-processing result. If yes, go to step 307; otherwise, go to step 309.
  • the pre-processing includes: determining, according to the ID of the notification message, whether the message has been received; determining whether it is necessary to receive according to the subtype of the notification message; determining the priority of the message, determining whether immediate processing is required; determining according to the version information of the message Whether to update the existing message; According to the Valid to time, determine whether the message expires; According to the provider ID of the notification message, determine whether the user cares about the message, and whether the content of the notification message needs to be processed.
  • Step 307 If the notification message needs to be processed, the terminal decompresses the payload of the Length indication length according to the compression manner of the notification message.
  • the notification message is synchronized with the program according to the synchronization time stamp, and the decompressed payload content is processed. Step 308, ending the process.
  • Step 309 Discard the notification message.
  • the notification message (such as the example of the notification message of Table 3) is set in the type designation extension field, and after receiving the notification message, the terminal processes the message according to each parameter. After the decision has to be processed, at the time of the program's playback, the message "Start voting now" can be displayed on the user terminal.
  • accurate synchronization of the notification message with the program stream can be achieved by carrying the notification message on the RTCP SR packet. Since the RTCP SR packet uses the same IP address as the associated program stream, but the port number is different, the terminal does not need to listen for additional IP addresses.
  • This embodiment describes a method of extending another RTCP packet (i.e., an application-defined RTCP packet), encapsulating a notification message in an application-defined RTCP packet, and decapsulating an application-defined RTCP packet to obtain a notification message.
  • another RTCP packet i.e., an application-defined RTCP packet
  • the format of the application-defined RTCP packet is defined as follows:
  • PT Used to determine whether the RTCP packet is an application-defined RTCP packet based on the value (such as 204).
  • Name ASCII name character code: Used to indicate whether the transmission in the application-dependent data is a notification message according to the value (for example, "Noti").
  • Application Linked Data Used to transmit notification messages.
  • the application association data field needs to be extended in order to transmit the notification message.
  • the format of the extended application association data field contains the following parameters: Parameter name parameter description
  • Timestamp synchronization timestamp used to synchronize with the program
  • Notification message ID The ID of the notification message
  • Subtype of subtype notification message which can be used to filter notification messages
  • Version information Version information compress type
  • the compression mode of the notification message such as 0x00 is uncompressed, 0x01 is Bim compression, 0x02 is Gzip compression, etc.
  • Length notification message The length of the payload
  • 0x0000 means there is no valid time providerID of the providerlD notification message
  • Notification message payload The content of the notification message
  • the message source After the extended format of the application associated data field is determined, when a notification message is generated, the message source generates a notification message payload synchronized with the program according to the program content, and determines parameter information such as a synchronization time stamp, a notification message ID, and a notification message subtype. After that, the parameters such as the notification message payload, the notification message ID, and the notification message subtype may be encapsulated into the RTCP corresponding to the synchronization timestamp.
  • the terminal On the RTCP packet receiving side (taking the terminal as an example), the terminal obtains the RTCP packet obtaining notification message according to the obtained application. As shown in FIG. 4, the following describes the process of decapsulating the application-defined RTCP packet to obtain the notification message.
  • Step 402 Obtain a notification message according to the value of the name ASCII (for example, "Noti").
  • Step 403 Perform pre-processing on the notification message, and determine whether to perform processing according to the pre-processing result. If yes, go to step 404, otherwise go to step 405.
  • the pre-processing includes: determining, according to the ID of the notification message, whether the message has been received; determining whether it is necessary to receive according to the subtype of the notification message; determining the priority of the message, determining whether immediate processing is required; determining according to the version information of the message Whether to update the existing message; According to the Validto time, determine whether the message expires; According to the provider ID of the notification message, determine whether the user cares about the message, and whether the message needs to be processed.
  • Step 404 The terminal decompresses the payload of the length indication length according to the compression manner of the notification message.
  • the message is synchronized with the program according to the synchronization time stamp, and the decompressed payload content is processed.
  • Step 405 the message will be discarded.
  • accurate synchronization of the notification message and the program stream can be achieved by carrying the notification message on the application-associated RTCP packet. Since the RTCP packet uses the same IP address as the associated program stream, but the port number is different, the terminal does not need to listen for additional IP addresses.
  • This embodiment describes a method of extending another RTP packet, encapsulating the notification message in the RTP packet, and decapsulating the RTP packet to obtain a notification message.
  • the format of the RTP packet is defined as follows:
  • RTP payload Used to carry notification messages. It can contain multiple notification messages, each of which contains the following parameters: Parameter name parameter description
  • Notification message ID The ID of the notification message
  • Subtype of subtype notification message which can be used to filter notification messages
  • Version information Version information compress type
  • the compression mode of the notification message such as 0x00 is uncompressed, 0x01 is Bim compression, 0x02 is Gzip compression, etc.
  • Length notification message The length of the payload
  • 0x0000 means there is no valid time providerID of the providerlD notification message
  • Notification message payload The content of the notification message
  • the message source After determining the format of the RTP packet, that is, after determining the PT and RTP payload formats, the message source generates a notification message payload synchronized with the program according to the program content, and determines a synchronization time stamp, a notification message ID, and a notification.
  • the parameter information such as the message subtype
  • parameters such as the notification message payload, the notification message ID, and the notification message subtype are encapsulated into the RTP packet corresponding to the synchronization timestamp.
  • the terminal On the RTP packet receiving side (taking the terminal as an example), the terminal obtains a notification message according to the obtained RTP packet. As shown in FIG. 5, the following describes the process of decapsulating the RTP packet to obtain a notification message.
  • Step 501 The terminal receives the RTP session, and obtains an RTP packet for transmitting the notification message according to the PT.
  • Step 502 The terminal performs pre-processing on the notification message, and determines whether to perform processing according to the pre-processing result. If yes, step 503 is performed, otherwise step 504 is performed. .
  • the pre-processing includes: determining, according to the ID of the notification message, whether the message has been received; determining whether it is necessary to receive according to the subtype of the notification message; determining the priority of the message, determining whether immediate processing is required; determining according to the version information of the message Whether it is necessary to update the existing message; according to the Valid to time, determine whether the message is expired; Know the provider ID of the message, determine whether the user is concerned about the message, and whether the message needs to be processed.
  • Step 503 The terminal decompresses the payload of the Length indicating length according to the compression manner of the notification message. Synchronize the message with the program according to the synchronization timestamp, and process the decompressed RTP payload content.
  • Step 504 Discard the notification message.
  • accurate synchronization of the notification message with the program stream can be achieved by carrying the notification message on the RTP packet.
  • this embodiment describes a system for transmitting a notification message, including:
  • a message source entity configured to generate a notification message synchronized with the program and a synchronization time stamp synchronized with the program, where the program source entity and the message source entity are in one-to-one correspondence;
  • Sending a notification message device configured to obtain a notification message synchronized with the program and a synchronization timestamp synchronized with the program, and encapsulate the notification message in an RTP/RTCP packet corresponding to the synchronization timestamp, and send the RTP/RTCP packet Receiving a notification message device;
  • a notification message device configured to receive an RTP/RTCP packet sent by the notification message device, obtain a notification message from the RTP/RTCP packet, and process the notification message.
  • the sending notification message device includes: an obtaining module, configured to obtain a notification message synchronized with the program, and obtain a synchronization time stamp synchronized with the program; and an RTP/RTCP packet encapsulating module, configured to encapsulate the notification message into the obtaining module
  • the synchronization time stamp corresponds to the RTP/RTCP packet; the sending module is configured to send the RTP/RTCP packet obtained by the RTP/RTCP packet encapsulation module to the receiving notification message device.
  • the receiving notification message device includes: a receiving module, configured to receive an RTP/RTCP packet sent by the sending notification message device; and an RTP/RTCP packet decapsulation module, configured to decapsulate the RTP/RTCP packet received by the receiving module Obtaining a notification message and processing the notification message according to the format of the notification message.
  • the RTP/RTCP packet decapsulation module includes: obtaining a submodule, configured to decapsulate an RTP/RTCP packet received by the receiving module to obtain a notification message; and a preprocessing submodule, configured to The notification message obtained by the obtaining sub-module is pre-processed, and the processing sub-module or the discarding sub-module is started according to the pre-processing result; the processing sub-module is configured to process the notification message; and the discarding sub-module is configured to discard the notification Message.
  • Embodiments of the present invention enable the notification message to be accurately synchronized with the program stream by carrying a notification message in the RTP/RTCP packet.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

说 明 书 发送、 接收通知消息的方法、 装置及系统 技术领域 本发明涉及一种通信技术， 尤其涉及一种发送、 接收通知消息的方法、 装 置及系统。 背景技术 随着因特网 （Internet ) 的迅猛发展， 大量多媒体业务得到了广泛的应用， 如移动视频、 电视广播、 视频会议、 网上教育、 互动游戏等。
目前支持所述多媒体业务应用的无线通信系统很多， 包括基于地面广播技 术的无线通信系统， 如欧洲的数字视频手持广播 （ Digital Video Broadcasting-Handheld, 简称 "DVB-H" ) 系统、 韩国的陆地数字多媒体广播 ( Terrestrial-Digital Multimedia Broadcasting, 简称 "T-DMB" ) 系统、 以及美 国 Qualcomm推出的 MediaFLO系统等； 基于卫星传播技术的无线通信系统， 如 欧洲的卫星数字多媒体广播 ( Satellite Digital Multimedia Broadcasting, 简称 " SDMB" ) 系统； 基于移动网络的第三代合作伙伴项目 （ 3rd Generation Partnership Proj ect , 简称 " 3 GPP " ) 中多媒体广播和组播业务（ Multimedia Broadcast/Multicast Service , 简称 "MBMS" )技术、 广播多播业务（ Broadcast Multicast Service, 简称 " BCMCS" )技术和流媒体技术。
所述无线通信系统包括： 服务器， 用于产生并下发实时传输协议 /实时 传输控制协议（RTP/RTCP ) 包、 通知消息； 和终端， 用于接收服务器下发 的 RTP/RTCP包、 通知消息， 并根据通知消息处理 RTP/RTCP包。
所述通知消息是指在某些事件（如紧急突发事件、 系统故障事件、 节目内 容介绍事件、 软件更新事件等）发生时， 在移动广播系统内由运营商向用户或 终端发送的消息， 以通知终端该事件的内容， 使用户终端进行相应的处理。 其 中有一种通知消息与节目相关， 例如， 用户观看节目时， 在某一关键情节发送 的有奖问答题， 或者与节目相关字幕， 这些通知消息的内容需要与节目内容保 持同步， 才能体现通知消息的意义。
现有的通知消息是 XML文本的格式， 消息格式如下所示:
Figure imgf000004_0001
由上述通知消息的格式可以看出， 在通知消息中有 PresentationRule (展示 规则 )子元素， 它包含 renderingTime (展示时间 )属性， 由于展示时间是一个 绝对时间， 而节目流的时间戳通常为相对时间， 因此无法做到使通知消息与节 目流实现精确的同步。 这样， 就会使得通知消息不能在节目流中与其对应的节 目帧中显示， 可能会导致通知消息与其实际表达的内容不相符， 如通知消息为 节目字幕时， 如果通知消息不能在其对应节目帧中显示， 可能就会失去其对帧 中的语音的解释作用。 发明内容
本发明的实施例提供了一种发送、 接收通知消息的方法、 装置和系统， 用 于解决通知消息不能与节目流精确同步的问题。
本发明的实施例提供了一种发送通知消息的方法， 包括：
获得与节目同步的通知消息， 并获得与节目同步的同步时间戳； 将所述通知消息封装到与所述同步时间戳对应的实时传输协议 /实时传输 控制协议 RTP/RTCP包中； 将所述 RTP/RTCP包发给终端。
本发明实施例还公开了一种接收通知消息的方法， 包括：
接收包括通知消息的 RTP/RTCP包；
解封装所述 RTP/RTCP包以获得所述通知消息。
本发明实施例还公开了一种发送通知消息装置， 包括：
获得模块， 用于获得与节目同步的通知消息， 并获得与节目同步的同步时 间戳；
RTP/RTCP包封装模块 , 用于将通知消息封装到与所述获得模块得到的同 步时间戳对应的 RTP/RTCP包中；
发送模块， 用于发送所述 RTP/RTCP包封装模块得到的 RTP/RTCP包。 本发明实施例还公开了一种接收通知消息装置， 包括：
接收模块， 用于接收发送通知消息装置发送的 RTP/RTCP包；
RTP/RTCP包解封装模块，用于对所述接收模块接收的 RTP/RTCP包进行解 封装以获得通知消息， 并根据所述通知消息的格式对所述通知消息进行处理。
本发明实施例还公开了一种传输通知消息的系统， 包括：
消息源实体， 用于产生与节目同步的通知消息以及与节目同步的同步时间 戳， 并将所述通知消息和所述同步时间戳发给发送通知消息装置；
发送通知消息装置， 用于获得所述消息源实体产生的与节目同步的通知消 息以及与节目同步的同步时间戳， 并将所述通知消息封装在与所述同步时间戳 对应的 RTP/RTCP包中， 将该 RTP/RTCP包发给接收通知消息装置。
本发明的实施例通过在 RTP/RTCP包中承载通知消息， 使得通知消息与节 目流精确同步。 附图说明 图 1示出了本发明实施例的传输通知消息的流程；
图 2示出了本发明实施例一解封装 RTP/RTCP包以获得通知消息的流程； 图 3示出了本发明实施例二解封装 RTP/RTCP包以获得通知消息的流程； 图 4示出了本发明实施例三解封装 RTP/RTCP包以获得通知消息的流程； 图 5示出了本发明实施例四解封装 RTP/RTCP包以获得通知消息的流程； 图 6示出了本发明实施例五的传输通知消息的系统。 具体实施方式 为了便于本领域一般技术人员理解和实现本发明，现结合附图描绘本发明 的实施例。
如图 1所示， 本发明实施例提供了一种传输通知消息的方法， 包括： 步骤 1、 获得与节目同步的通知消息、 并获得与节目同步的同步时间戳。 步骤 2、 将所述通知消息封装到与所述同步时间戳对应的 RTP/RTCP包中。 步骤 3、 将所述的 RTP/RTCP包发给用户终端。
步骤 4、 用户终端对所述 RTP/RTCP包进行解封装以获得通知消息。
在步骤 2和步骤 4中， 为了将通知消息封装到与所述同步时间戳对应的 RTP/RTCP包中， 根据本发明实施例， 首先需要扩展 RTP/RTCP包的格式， 然后 将通知消息封装到所述 RTP/RTCP包中。 在实施例一至四中介绍几种扩展 RTP/RTCP包格式的方法、 相应的将通知消息封装到所述 RTP/RTCP包中的方 法、 相应的对所述 RTP/RTCP包进行解封装以得到通知消息的方法。
实施例一
本实施例描述扩展 RTP包头、 将通知消息封装在 RTP包头中、 解封装 RTP 包头以获得通知消息的方法。
( 1 )扩展 RTP包头
为了传输通知消息， 需要在 RTP包的包头中设置通知消息指示位和确定承 载通知消息的字段。 在本实施例中， 对 RTP包头的扩展字段进行扩展， 所述扩 展字段包括： "defined by profile" (类型定义）字段、 length (长度）和 header extension (扩展头） 。 取扩展字段中的类型定义字段作为通知消息标志字段， 当通知标志字段设置为有效时（如设置为 "0xC051" ) , 表示 RTP包的包头中 含有通知消息， 否则， RTP包的包头中不含有通知消息； 将扩展字段的 header extension (扩展头） 字段作为承载通知消息的字段。 这样， RTP包头的格式如 下：
0 1 2 3
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
+ -+-+-+-+- + - + - + - + - + - + - + - +-+-+-+-+-+- + - +-+-+-+-+-+-+-+-+- + - +-+-+-
|V=2 |P|X| CC |Μ| ΡΤ sequence number
+ -+-+-+-+- + - + - + - + - + - + - + - +-+-+-+-+-+- + - +-+-+-+-+-+-+-+-+- + - +-+-+-
1 timestamp
+-+-+-+-+- + - + - + - + - + - + - + - +-+-+-+-+-+- + - +-+-+-+-+-+-+-+-+- + - +-+-+- synchronization source (SSRC) identifier
contributing source (CSRC) identifiers defined by profile | length
header extension
Figure imgf000007_0001
其中：
• V： version, 2bits, 用于标识所用 RTP协议的版本。 目前的 RTP版本为 2;
• P: padding, lbit, 如果置为 1, 则 payload的末尾有 1个或者多个填充字节。
其中最后一个填充字节， 标识了填充字节的总数目 （包括最后一个字节）。
• X： extension, lbit, 如果置为 1, 则固定的 RTP头后面必须 （must) 包含一 个且仅有一个头部扩展 ( head extension )。 头部扩展的格式见 3.2节。
• CC: CSRC count, 4bits, 标识该流的 CSRC数量。 它的个数决定了 RTP包头 的大小。
• M: marker, lbit, 该字段的含义根据 Profile的不同而不同， 具体由 Profile 决定。 Profile也可以不使用该字段， 而将 marker字段放入 payload中。
• PT (净荷类型）： ayload type, 7bits, 用于标识 RTP payload中承载的数据 为什么格式。 终端据此解析 payload。
參 Sequence number: 16bits, 序列号， 标识 RTP包的顺序。 在一个 RTP会话中， RTP包的序列号是顺序递增的。 RTP包的起始序列号必须是随机的。
• Timestamp: 32bits, 时间戳， 标识 RTP数据包中第一个字节的釆样时间。 终 端可通过该时间戳正确的恢复出原媒体流。 Timestamp还可以用于同步多个 媒体流， 关于 timestamp的同步机制参见 5.4节。
• SSRC: 32bits, 标识同步源。
• CSRC: 0 ~ 15个， 每个 32bits, 标识流的内容源。
• defined by profile: 通知消息标志字段， 当通知消息标志字段设置为有效时
(如设置为" 0xC051" ), 表示 RTP包的包头中含有通知消息， 否则， RTP包 的包头中不含有通知消息。
• 扩展头： 承载通知消息的字段。
header extension字段的扩展头可设置多个通知消息， 每个通知消息的参数 口下所示：
Figure imgf000008_0001
( 2 )将通知消息封装在 RTP包头中
当通知消息标志字段和承载通知消息的字段确定后， 消息源根据节目内容 产生与节目同步的通知消息净荷， 并确定同步 timestamp (时间戳）、 通知消息 标识、 通知消息子类型等参数信息后， 将通知消息净荷以及通知消息标识、 通 知消息子类型等参数封装到与同步时间戳对应的 RTP包头中。 然后将 RTP包头 和节目一起发送给终端。
( 3 )解封装 RTP包头以获得通知消息
在 RTP包接收侧 （以终端为例 ) , 终端监听发送节目 RTP包的 IP地址和端 口号， 获得 RTP包， 如图 2所示， 下面描述解封装 RTP包以获得通知消息。
步骤 201、 根据 PT, 获得 RTP包， 即终端解析 RTP包头， 判断是否有扩展 头。
步骤 202、 判断是否有扩展头， 如果是， 执行步骤 203 , 否则执行步骤 208。 即， 通过 RTP包头中的 "X" 字段（参见本实施例中的 RTP包头描述部分） 来判断是否有扩展头， 如果 "X" 字段为 1 , 则表示有扩展头， 如果 "X" 字段 为 0时， 表示没有扩展头。
步骤 203、 根据扩展头的 defined by profile字段判断是否存在通知消息， 如 果是， 执行步骤 204, 否则执行步骤 208。
即通过通知标志字段指示存在通知消息时（如设置为" 0xC051" ) ,表示 RTP 包的包头中含有通知消息， 否则， RTP包的包头中不含有通知消息。
步骤 204、 从 RTP包头的扩展头扩展头中获得通知消息。
步骤 205、 终端根据定义的消息格式对每个通知消息进行预处理， 并根据 预处理结果判断是否对通知消息进行处理， 如果是， 则执行步骤 207 , 否则， 执行步骤 206。 所述预处理包括： 根据通知消息的 ID确定消息是否已经收到过； 根据通知消息的子类型， 判断是否需要接收； 通知消息的优先级， 决定是否需 要立即处理； 根据消息的版本信息， 判断是否需要对已有消息进行更新； 根据 Valid to时间， 判断消息是否过期； 根据通知消息的提供商 ID, 判断用户是否对 消息关心， 是否需要对消息进行处理等。
步骤 206、 丟弃此消息， 然后执行步骤 208。
步骤 207、 终端根据通知消息的压缩方式， 对 Length指示长度的 payload进 行解压缩。 根据同步时间戳将通知消息与节目进行同步， 对解压后的 payload 内容进行处理。 步骤 208、 对 RTP包中的节目数据进行处理。
在本实施例中， 通过将通知消息设置在与其同步时间戳的 RTP包的扩展头 中， 使得通知消息与节目流的准确同步。 由于通知消息与节目流使用相同的 RTP包， 终端只需要对节目所在的地址和端口号进行监听。
实施例二
本实施例描述扩展 RTCP SR( RTCP发送报告）包、将通知消息封装在 RTCP SR包中、 解封装 RTCP SR包以获得通知消息的方法。
(1)扩展 RTCP SR包
RTCP SR包结构如下所示:
2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 2 3 4 5 6 7 8 9 0
V=2 P RC PT=SR=200 I length
SSRC of sender
NTP time stam , most significant word
NTP time stam , least significant word
RTP time stamp
sender' s packet count
sender' s octet count
SSRC 1 (SSRC of first source
fraction lost | cumulative number of packets lost
extended highest sequence number received
interarrival itter
last SR (LSR)
delay since last SR (DLSR)
SSRC 2 (SSRC of second source prof ile- specific extensions 其中 Header部分：
I V: 版本， 目前统一取 V = 2;
P: padding, 同 RTP包；
RC , Reception report Count , 标识包含接收报告的数量； • PT: Pack Type, 取 200表示 RTCP的 SR包；
• Sender information: 发送者信息。
• SSRC of sender: 当前发送报告的发送者的 S SRC值。 參 NTP timestamp: 发送这个发送才艮告的 NTP釆样时间；
• RTP timestamp: 发送这个发送报告时的 RTP釆样时间， 这里的 RTP釆样 时间与 RTP会话里的釆样时间一致。
• sender's packet count: 发送者从发送开始到当前时刻 （NTP )发送的所 有 RTP包的数量。 如果发送者的 SSRC改变， 则这个数值需要 reset。
• sender's octet count: 发送者从发送开始到当前时刻 （ NTP )发送的所有
RTP包的负载的字节数量。 如果发送者的 SSRC改变， 则这个数值需要 reset。
• profile-specific extensions: 类型指定扩展。 在 RTP/RTCP协议中规定， 这 一字段由 profile定义。 对类型指定扩展字段作扩展， 用来传输通知消息， 其包含如下参数： 参数名称 参数描述 type 扩展所携带的信息类型， 需要标识为通知消息
Notification message ID 通知消息的 ID
Subtype 通知消息的子类型， 可用于过滤通知消息
Privilege 通知消息的优先级， 如 0x01必须处理， 0x02可不处理
Version 消息的版本信息 compress type 通知消息的压缩方式，如取 0x00为未压缩， 0x01为 Bim压缩， 0x02 为 Gzip压缩等等
Length 通知消息 payload的字节长度 Valid to 通知消息的有效时间段的结束时间， 使用 RTP timestamp时间， 取
0x0000表示没有有效时间
providerlD 通知消息的提供商 ID
Notification message payload 通知消息的内容 其中， type (类型） ， 用来标识在类型指定扩展字段中是否携带的是通知 消息， 即， 当 type设置为有效（如设置为： 0x0001 )时， 则表示类型指定扩展 字段携带有通知消息， 否则， 则表示类型指定扩展字段没有携带通知消息。 其 它字段的内容为通知消息的参数和通知消息的内容。 类型指定扩展字段的内容 可以具体为：
Figure imgf000012_0001
( 2 )将通知消息封装在 RTCP SR包中
确定了类型指定扩展字段的扩展格式后， 则当有通知消息产生时， 可将通 知消息封装到 RTCP SR包中， 封装置方法如下： 消息源根据节目内容产生与节目同步的通知消息净荷， 并确定同步时间 戳、 通知消息 ID、 通知消息子类型等参数信息。
将通知消息净荷， 以及通知消息 ID、 通知消息子类型等参数封装到同步时 间戳对应的 RTCP SR包的类型指定扩展字段中。
( 3 )解封装 RTCP SR包以获得通知消息
在 RTP SR包接收侧 （以终端为例） ， 终端通过接入 RTCP SR包以获得通 知消息， 如图 3所示， 下面描述解封装 RTCP SR包以获得通知消息的流程。
步骤 301、 终端接收 RTCP会话， 根据 PT = 200过滤 RTCP包， 获得 RTCP SR 包。
步骤 302、 根据 NTP timestamp和 RTP time stamp获得与承载节目流 RTP的同 步信息。
步骤 303、 获得对节目源 SSRC— n的接收信息。
步骤 304、 终端根据 Length是否超过预定值判断获得的 RTCP SR包中是否 包含类型指定扩展字段， 如果是， 执行步骤 305 , 否则， 执行步骤 308。
步骤 305、终端根据类型指定扩展字段的 type参数，判断类型指定扩展字段 中是否携带了通知消息， 如果是， 执行步骤 306, 否则， 执行步骤 308。
步骤 306、 终端根据类型指定扩展字段的格式进行预处理， 并根据预处理 结果判断是否对通知消息进行处理， 若是，执行步骤 307 , 否则，执行步骤 309。 所述预处理包括： 根据通知消息的 ID确定消息是否已经收到过； 根据通知消息 的子类型， 判断是否需要接收； 通知消息的优先级， 决定是否需要立即处理； 根据消息的版本信息， 判断是否需要对已有消息进行更新； 根据 Valid to时间， 判断消息是否过期； 根据通知消息的提供商 ID, 判断用户是否对消息关心， 是 否需要对通知消息内容进行处理。
步骤 307、 若需要对此通知消息进行处理， 终端根据通知消息的压缩方式， 对 Length指示长度的净荷（payload )进行解压缩。 根据同步时间戳将通知消息 与节目进行同步， 对解压后的净荷（payload ) 内容进行处理。 步骤 308、 结束本过程。
步骤 309、 丟弃此通知消息。
这样， 本实施例中， 当产生通知消息后， 将该通知消息 （如表 3的通知消 息的例子）设置在类型指定扩展字段中， 终端收到此通知消息后， 根据各参数 对消息进行处理， 判定必须处理后， 在节目的播放时刻， 可在用户终端展示信 息 "现在开始投票" 。
在本实施例中， 通过在 RTCP SR包上承载通知消息， 可以实现通知消息与 节目流的准确同步。 由于 RTCP SR包与相关的节目流使用相同的 IP地址， 只是 端口号不同， 终端不需要监听额外的 IP地址。
实施例三
本实施例描述扩展另一种 RTCP包（即， application-defined RTCP (应用限 定 RTCP)包）、将通知消息封装在应用限定 RTCP包中、解封装应用限定 RTCP 包以获得通知消息的方法。
( 1 )扩展应用限定 RTCP包
应用限定 RTCP包的格式定义如下：
0 1 2 3
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
I V=2 I P I subtype | PT | length |
1 SSRC/CSRC I
I name ASCII |
I application -dependent data ... |
在上面格式中，
PT: 用于根据取值（如取 204)可确定 RTCP包是否为应用限定 RTCP包。 name ASCII (名字字符码） ： 用于根据取值 （如， 取为 "Noti" )指示 application-dependent data (应用关联数据 ) 中传输的是否为通知消息。
应用关联数据： 用于传输通知消息。
为了传输通用通知消息， 需要扩展应用关联数据字段以便传输通知消息。 扩展后的应用关联数据字段的格式包含如下参数： 参数名称 参数描述
Timestamp 同步时间戳， 用于与节目进行同步
Notification message ID 通知消息的 ID
Subtype 通知消息的子类型， 可用于过滤通知消息
Privilege 通知消息的优先级， 如 0x01必须处理， 0x02可不处理
Version 消息的版本信息 compress type 通知消息的压缩方式，如取 0x00为未压缩， 0x01为 Bim压缩， 0x02 为 Gzip压缩等等
Length 通知消息 payload的字节长度
Valid to 通知消息的有效时间段的结束时间， 使用 RTP timestamp时间， 取
0x0000表示没有有效时间 providerlD 通知消息的提供商 ID
Notification message payload 通知消息的内容
( 2 )将通知消息封装在应用限定 RTCP包中
确定了应用关联数据字段的扩展格式后， 则当有通知消息产生， 消息源根 据节目内容产生与节目同步的通知消息净荷，并确定同步时间戳、通知消息 ID、 通知消息子类型等参数信息后， 可将通知消息净荷、 通知消息 ID、 通知消息子 类型等参数封装到同步时间戳对应的 RTCP中。
( 3 )解封装应用限定 RTCP包以获得通知消息
在 RTCP包接收侧（以终端为例）， 终端根据获得的应用限定 RTCP包获得 通知消息， 如图 4所示， 下面描述解封装应用限定 RTCP包以获得通知消息的流 程。
步骤 401、 终端接收 RTCP会话， 根据 PT的取值（如 PT = 204 )获得应用限 定 RTCP包。
步骤 402、 根据 name ASCII的取值（如为 "Noti" )获得通知消息。
步骤 403、 对通知消息进行预处理， 并根据预处理结果判断是否进行处理， 如果是， 执行步骤 404, 否则执行步骤 405。 所述预处理包括： 根据通知消息的 ID确定消息是否已经收到过； 根据通知消息的子类型， 判断是否需要接收； 通 知消息的优先级， 决定是否需要立即处理； 根据消息的版本信息， 判断是否需 要对已有消息进行更新； 根据 Validto时间， 判断消息是否过期； 根据通知消息 的提供商 ID, 判断用户是否对消息关心， 是否需要对消息进行处理。
步骤 404、 终端根据通知消息的压缩方式， 对 Length指示长度的 payload进 行解压缩。根据同步时间戳将消息与节目进行同步，对解压后的 payload内容进 行处理。
步骤 405、 将丟弃此消息。
在本实施例中， 通过在应用关联 RTCP包上承载通知消息， 可以实现通知 消息与节目流的准确同步。 由于 RTCP包与相关的节目流使用相同的 IP地址， 只是端口号不同， 终端不需要监听额外的 IP地址。
实施例四
本实施例描述扩展另一种 RTP包、将通知消息封装在 RTP包中、解封装 RTP 包以获得通知消息的方法。
(1)扩展 RTP包
RTP包的格式定义如下：
1 2 3
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
- + - + - + - + - - + - + -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + - - + - - + - - + - - +
V=2 |χ| cc 1 M 1 PT 1 sequence number 1
■- + - + - + - + - - + - + -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + - - + - - + - - + - - +
time stamp 1
■- + - + - + - + - - + - + -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + - - + - - + - - + - - +
synchronization source (SSRC) identifier 1
■ = + = + = + = + = = + = + : : + = = + = = + = = + = = +
contributing source (CSRC) identifiers
1
■- + - + - + - + - - + - + -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + - - + - - + - - + - - +
RTP payload .... 1
■- + - + - + - + - - + - + -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + - - + - - + - - + - - +
在上述 RTP格式中，
PT: 用于根据其取值 (如 PT=255 )标识 RTP payload中携带的是通知消息。
RTP payload: 用于承载通知消息。 其可以包含多个通知消息， 每个通知消 息包含如下参数： 参数名称 参数描述
Notification message ID 通知消息的 ID
Subtype 通知消息的子类型， 可用于过滤通知消息
Privilege 通知消息的优先级， 如 0x01必须处理， 0x02可不处理
Version 消息的版本信息 compress type 通知消息的压缩方式，如取 0x00为未压缩， 0x01为 Bim压缩， 0x02 为 Gzip压缩等等
Length 通知消息 payload的字节长度
Valid to 通知消息的有效时间段的结束时间， 使用 RTP timestamp时间， 取
0x0000表示没有有效时间 providerlD 通知消息的提供商 ID
Notification message payload 通知消息的内容
( 2 )将通知消息封装在 RTP包中
当确定了上述 RTP包的格式后， 即确定了上述的 PT和 RTP payload格式后， 当消息源根据节目内容产生与节目同步的通知消息净荷， 并确定同步时间戳、 确定通知消息 ID、 通知消息子类型等参数信息后， 将通知消息净荷、 通知消息 ID、 通知消息子类型等参数封装到同步时间戳对应的 RTP包中。
( 3 )解封装 RTP包以获得通知消息
在 RTP包接收侧 （以终端为例） ， 终端根据获得的 RTP包获得通知消息， 如图 5所示， 下面描述解封装 RTP包以获得通知消息的流程。
步骤 501、 终端接收 RTP会话， 根据 PT得到传输通知消息的 RTP包； 步骤 502、 终端对通知消息进行预处理， 并根据预处理结果判断是否进行 处理， 如果是， 执行步骤 503 , 否则执行步骤 504。 所述预处理包括： 根据通知 消息的 ID确定消息是否已经收到过； 根据通知消息的子类型， 判断是否需要接 收； 通知消息的优先级， 决定是否需要立即处理； 根据消息的版本信息， 判断 是否需要对已有消息进行更新； 根据 Valid to时间， 判断消息是否过期； 根据通 知消息的提供商 ID, 判断用户是否对消息关心， 是否需要对消息进行处理。 步骤 503、 终端根据通知消息的压缩方式， 对 Length指示长度的 payload进 行解压缩。 根据同步时间戳将消息与节目进行同步， 对解压后的 RTP payload 内容进行处理。
步骤 504、 丟弃通知消息。
在本实施例中， 通过在 RTP包上承载通知消息， 可以实现通知消息与节目 流的准确同步。
实施例五
如图 6所示， 本实施例描述传输通知消息的系统， 包括：
节目源实体， 用于产生节目；
消息源实体， 用于产生与节目同步的通知消息以及与节目同步的同步时间 戳， 所述节目源实体和消息源实体是一一对应的；
发送通知消息装置， 用于获得与节目同步的通知消息以及与节目同步的同 步时间戳， 并将所述通知消息封装在与同步时间戳对应的 RTP/RTCP包中， 将 该 RTP/RTCP包发给接收通知消息装置；
接收通知消息装置， 用于接收发送通知消息装置发送的 RTP/RTCP包， 从 该 RTP/RTCP包中获得通知消息， 并处理该通知消息。
所述发送通知消息装置， 包括： 获得模块， 用于获得与节目同步的通知消 息、 并获得与节目同步的同步时间戳； RTP/RTCP包封装模块， 用于将通知消 息封装到与获得模块得到的同步时间戳对应的 RTP/RTCP包中； 发送模块， 用 于将所述 RTP/RTCP包封装模块得到的 RTP/RTCP包发给接收通知消息装置。
所述接收通知消息装置， 包括： 接收模块， 用于接收发送通知消息装置发 送的 RTP/RTCP包； RTP/RTCP包解封装模块， 用于对所述接收模块接收的 RTP/RTCP包进行解封装以获得通知消息， 并根据所述通知消息的格式对所述 通知消息进行处理。 所述 RTP/RTCP包解封装模块包括： 获得子模块， 用于解 封装接收模块收到的 RTP/RTCP包以获得通知消息； 预处理子模块， 用于对所 述获得子模块获得的通知消息进行预处理， 并根据预处理结果启动处理子模块 或丢弃子模块； 处理子模块， 用于处理所述通知消息； 丟弃子模块， 用于丟弃 所述通知消息。
本发明的实施例通过在 RTP/RTCP包中承载通知消息， 使得通知消息与节 目流精确同步。
虽然通过实施例描绘了本发明， 但本领域普通技术人员知道， 在不脱离本 发明的精神和实质的情况下， 就可使本发明有许多变形和变化， 本发明的范围 由所附的权利要求来限定。

Claims

权 利 要 求 书
1、 一种发送通知消息的方法， 其特征在于， 包括：
获得与节目同步的通知消息， 并获得与节目同步的同步时间戳； 将所述通知消息封装到与所述同步时间戳对应的实时传输协议 /实时传输 控制协议 RTP/RTCP包中；
将所述 RTP/RTCP包发给终端。
2、 根据权利要求 1所述的方法， 其特征在于， 所述将通知消息封装到与所 述同步时间戳对应的 RTP/RTCP包中具体包括： 将 RTP包头中的头扩展字段的 类型定义字段设置为指示有通知消息状态， 将所述通知消息设置在所述 RTP包 头的头扩展字段的扩展头字段中。
3、 根据权利要求 1所述的方法， 其特征在于， 所述将通知消息封装到与所 述同步时间戳对应的 RTP/RTCP包中具体包括：将 RTCP发送才艮告包中的类型指 定扩展字段的通知消息指示字段设置为指示有通知消息状态， 将所述通知消息 设置在所述类型指定扩展字段的通知消息字段中。
4、 根据权利要求 1所述的方法， 其特征在于， 所述将通知消息封装到与所 述同步时间戳对应的 RTP/RTCP包中具体包括：将应用限定 RTCP包中的名字字 符码字段设置为指示有通知消息状态， 将所述通知消息设置在所述应用限定 RTCP包中的应用关联数据字段中。
5、 根据权利要求 1所述的方法， 其特征在于， 所述将通知消息封装到与所 述同步时间戳对应的 RTP/RTCP包中具体包括： 将 RTP包中的 PT字段设置为指 示有通知消息状态， 将所述通知消息设置在所述 RTP包中的 RTP净荷字段中。
6、 一种接收通知消息的方法， 其特征在于， 包括：
接收包括通知消息的 RTP/RTCP包；
解封装所述 RTP/RTCP包以获得所述通知消息。
7、 根据权利要求 6所述的方法， 其特征在于， 所述 RTP包头的头扩展字段 的类型定义字段指示有通知消息， 所述解封装所述 RTP/RTCP包以获得所述通 知消息具体为：
8、 根据权利要求 6所述的方法， 其特征在于， 所述 RTCP包具体为 RTCP发 送报告包， 且所述 RTCP发送报告包的类型指定扩展字段的通知消息指示位指 示有通知消息， 所述解封装所述 RTP/RTCP包以获得所述通知消息具体为： 从所述 RTCP发送报告包中的类型指定扩展字段中获得所述通知消息。
9、 根据权利要求 6所述的方法， 其特征在于， 所述 RTCP包具体为应用限 定 RTCP包， 且所述应用限定 RTCP包的名字字符码字段指示有通知消息， 所述 解封装所述 RTP/RTCP包以获得所述通知消息具体为：
从所述应用限定 RTCP包中的应用关联数据字段中获得所述通知消息。
10、 根据权利要求 6所述的方法， 其特征在于， 所述 RTP包的 PT字段指示 有通知消息， 所述解封装所述 RTP/RTCP包以获得所述通知消息具体为：
从所述 RTP包中的 RTP净荷字段中获得所述通知消息。
11、 一种发送通知消息装置， 其特征在于， 包括：
获得模块， 用于获得与节目同步的通知消息， 并获得与节目同步的同步时 间戳；
RTP/RTCP包封装模块 , 用于将通知消息封装到与所述获得模块得到的同 步时间戳对应的 RTP/RTCP包中；
发送模块， 用于发送所述 RTP/RTCP包封装模块得到的 RTP/RTCP包。
12、 一种接收通知消息装置， 其特征在于， 包括：
接收模块， 用于接收发送通知消息装置发送的 RTP/RTCP包；
RTP/RTCP包解封装模块，用于对所述接收模块接收的 RTP/RTCP包进行解 封装以获得通知消息， 并根据所述通知消息的格式对所述通知消息进行处理。
13、 根据权利要求 12所述的接收通知消息装置， 其特征在于， 所述 RTP/RTCP包解封装模块包括：
获得子模块， 用于解封装所述接收模块收到的 RTP/RTCP包以获得通知消 息；
预处理子模块， 用于对所述获得子模块获得的通知消息进行预处理， 并根 据预处理结果启动处理子模块或丟弃子模块；
处理子模块， 用于处理所述通知消息；
丟弃子模块， 用于丟弃所述通知消息。
14、 一种传输通知消息的系统， 其特征在于， 包括：
消息源实体， 用于产生与节目同步的通知消息以及与节目同步的同步时间 戳， 并将所述通知消息和所述同步时间戳发给发送通知消息装置；
发送通知消息装置， 用于获得所述消息源实体产生的与节目同步的通知消 息以及与节目同步的同步时间戳， 并将所述通知消息封装在与所述同步时间戳 对应的 RTP/RTCP包中， 将该 RTP/RTCP包发给接收通知消息装置。
15、 根据权利要求 14所述的传输通知消息的系统， 其特征在于， 所述系统 还包括： 节目源实体， 用于产生节目， 并将所述节目发给封装通知消息装置。
PCT/CN2008/070088 2007-03-29 2008-01-11 Procédé, dispositif et système d'émission et de réception d'informations de message WO2008119268A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP08700107A EP2026531A4 (en) 2007-03-29 2008-01-11 METHOD, DEVICE AND SYSTEM FOR SENDING AND RECEIVING MESSAGE INFORMATION
US12/346,013 US20090110006A1 (en) 2007-03-29 2008-12-30 Method, apparatus and system for sending and receiving notification messages

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2007100869996A CN101277179B (zh) 2007-03-29 2007-03-29 发送、接收通知消息的方法、装置及系统
CN200710086999.6 2007-03-29

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/346,013 Continuation US20090110006A1 (en) 2007-03-29 2008-12-30 Method, apparatus and system for sending and receiving notification messages

Publications (1)

Publication Number Publication Date
WO2008119268A1 true WO2008119268A1 (fr) 2008-10-09

Family

ID=39807809

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/070088 WO2008119268A1 (fr) 2007-03-29 2008-01-11 Procédé, dispositif et système d'émission et de réception d'informations de message

Country Status (4)

Country Link
US (1) US20090110006A1 (zh)
EP (1) EP2026531A4 (zh)
CN (1) CN101277179B (zh)
WO (1) WO2008119268A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8255225B2 (en) 2008-08-07 2012-08-28 Vocollect Healthcare Systems, Inc. Voice assistant system
JP5438414B2 (ja) 2009-07-23 2014-03-12 パナソニック株式会社 明るさ検知システムおよびそれを用いた照明システム
WO2011014551A1 (en) * 2009-07-28 2011-02-03 Vocollect Healthcare Systems, Inc. Method and system for sending messages
CN102577304B (zh) * 2009-08-12 2015-12-09 荷兰皇家Kpn电信集团 动态转发第一协议的消息的方法和系统及其控制节点
CN103259640B (zh) * 2013-05-28 2016-08-31 杭州华三通信技术有限公司 一种同步时间的方法和设备
WO2020092818A1 (en) * 2018-11-02 2020-05-07 Intel Corporation Signaling codec mode notifications for multimedia telephony sessions
CN113765791B (zh) * 2020-06-02 2023-01-13 华为技术有限公司 一种确定处理能力的方法、节点和系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6359656B1 (en) * 1996-12-20 2002-03-19 Intel Corporation In-band synchronization of data streams with audio/video streams
CN1431660A (zh) * 2003-02-28 2003-07-23 清华大学 一种流媒体点播的音视频切换方法
US20050169268A1 (en) * 2000-05-02 2005-08-04 Nobuyoshi Tomita Data transmission device and data transmission method
WO2006016957A2 (en) 2004-07-09 2006-02-16 Cisco Technology, Inc. Method and apparatus for interleaving text and media in a real-time transport session
CN1802834A (zh) * 2003-08-18 2006-07-12 阿尔卡特公司 能够对附加数据进行传输的VoIP通信方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6934756B2 (en) * 2000-11-01 2005-08-23 International Business Machines Corporation Conversational networking via transport, coding and control conversational protocols
SE524599C2 (sv) * 2002-01-18 2004-08-31 Ericsson Telefon Ab L M Metod, system och datorprogramprodukt för att anordna tjänstekvalitet QoS
JP3836077B2 (ja) * 2002-11-14 2006-10-18 松下電器産業株式会社 伝送データ構造及びそれを伝送するための方法並びに装置
EP1530337B1 (en) * 2003-11-06 2006-09-06 Matsushita Electric Industrial Co., Ltd. Optimized transmission of text sample format descriptions for streaming timed text
JP4645281B2 (ja) * 2005-04-19 2011-03-09 ソニー株式会社 情報処理装置および方法、プログラム、並びに記録媒体
US20070268883A1 (en) * 2006-05-17 2007-11-22 Nokia Corporation Radio text plus over digital video broadcast-handheld
US8935420B2 (en) * 2007-03-09 2015-01-13 Nokia Corporation Method and apparatus for synchronizing notification messages
JP4600513B2 (ja) * 2008-04-25 2010-12-15 ソニー株式会社 データ送信装置、送信レート制御方法およびプログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6359656B1 (en) * 1996-12-20 2002-03-19 Intel Corporation In-band synchronization of data streams with audio/video streams
US20050169268A1 (en) * 2000-05-02 2005-08-04 Nobuyoshi Tomita Data transmission device and data transmission method
CN1431660A (zh) * 2003-02-28 2003-07-23 清华大学 一种流媒体点播的音视频切换方法
CN1802834A (zh) * 2003-08-18 2006-07-12 阿尔卡特公司 能够对附加数据进行传输的VoIP通信方法
WO2006016957A2 (en) 2004-07-09 2006-02-16 Cisco Technology, Inc. Method and apparatus for interleaving text and media in a real-time transport session

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
J.REY; Y.MATSUI: "RTP Payload Format for 3GPP Timed Text: draft-ietf-avt-rtp-3gpp-timed-text-07.txt", IETF STANDARD WORKING DRAFT, IETF, 8 October 2004 (2004-10-08)
See also references of EP2026531A4

Also Published As

Publication number Publication date
CN101277179B (zh) 2012-08-08
EP2026531A4 (en) 2009-07-22
US20090110006A1 (en) 2009-04-30
CN101277179A (zh) 2008-10-01
EP2026531A1 (en) 2009-02-18

Similar Documents

Publication Publication Date Title
EP1333639B1 (en) Communication terminal, server, relay apparatus, broadcast communication system, broadcast communication method, and program
KR101501347B1 (ko) 멀티미디어 시스템에서 미디어 컨텐츠 전송 방법
KR102265908B1 (ko) 지상파 방송망과 인터넷 프로토콜망 연동 기반의 하이브리드 방송 시스템에서 방송 서비스의 송수신 방법 및 장치
US8935420B2 (en) Method and apparatus for synchronizing notification messages
KR101757302B1 (ko) 하이브리드 방송 시스템의 방송 신호를 송신/수신하는 방법 및 장치
WO2008119268A1 (fr) Procédé, dispositif et système d'émission et de réception d'informations de message
EP3285491A1 (en) Method and apparatus for transmitting or receiving service signaling for broadcasting service
US11496542B2 (en) Apparatus for transmitting broadcast signal, apparatus for receiving broadcast signal, method for transmitting broadcast signal and method for receiving broadcast signal
JP5049151B2 (ja) 受信装置及び伝送システム
US11606293B2 (en) Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method
EP1881667A1 (en) Apparatus and method for presenting an event during a broadcast
WO2011137848A1 (zh) 广告拼接处理方法和系统以及拼接器和头端设备
US20100205317A1 (en) Transmission, reception and synchronisation of two data streams
JP2009524372A (ja) デジタルビデオサービスのブロードキャストまたは受信方法、および装置
JP2020074589A (ja) 送信方法
KR20080023902A (ko) 지상파 디지털 멀티미디어 방송 서비스의 인터넷 프로토콜패킷 재전송 장치
JP2024120983A (ja) 送信方法および送信装置
TW202215853A (zh) 用於適應性位元率多播的修復機制

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08700107

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2008700107

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE