WO2011000151A1 - 网络电视频道业务实现方法和相关设备 - Google Patents

网络电视频道业务实现方法和相关设备 Download PDF

Info

Publication number
WO2011000151A1
WO2011000151A1 PCT/CN2009/072543 CN2009072543W WO2011000151A1 WO 2011000151 A1 WO2011000151 A1 WO 2011000151A1 CN 2009072543 W CN2009072543 W CN 2009072543W WO 2011000151 A1 WO2011000151 A1 WO 2011000151A1
Authority
WO
WIPO (PCT)
Prior art keywords
channel
metadata
unicast
type
multicast
Prior art date
Application number
PCT/CN2009/072543
Other languages
English (en)
French (fr)
Inventor
余勇
许鑫
贾记磊
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2009/072543 priority Critical patent/WO2011000151A1/zh
Priority to CN2009801476169A priority patent/CN102150407B/zh
Publication of WO2011000151A1 publication Critical patent/WO2011000151A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1836—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with heterogeneous network architecture
    • 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • 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

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a method for implementing a network television channel service and related devices.
  • IPTV Internet Protocol Television
  • IP Internet Protocol
  • IP Multimedia Subsystem is a unified system architecture that integrates IP networks and communication services.
  • the existing IMS-based IPTV channel services are implemented through a multicast solution.
  • the service flow is shown in Figure 1:
  • the multicast channel session establishment request is initiated to the IMS core network (IMS Core), and the request may be an Invite message based on the SIP protocol.
  • IMS Core IMS core network
  • SDP Multicast Session Description
  • the IMS Core forwards the Invite request to a Resource and Admission Control Subsystem (RACS) to complete resource reservation and admission control;
  • RAS Resource and Admission Control Subsystem
  • the IMS Core forwards the Invite request to a Service Control Function (SCF);
  • SCF Service Control Function
  • the SCF performs an authorization check on the Invite request, and directly sends a confirmation message (200 OK) to the IMS Core after passing;
  • the IMS Core forwards the 200 OK response to the RACS to complete the resource submission;
  • the IMS Core forwards the 200 OK response to the UE;
  • the UE sends a final acknowledgement message (ACK) to the SCF.
  • ACK final acknowledgement message
  • the channel session is established, and the UE directly joins the multicast channel to receive the channel data stream.
  • the IMS channel-based IPTV channel service the user equipment (UE) acquires the channel data stream by joining the multicast channel, which requires the network to support the entire network multicast. If some networks or devices only support unicast, it is not supported. Multicast, then the IPTV channel service described in the above process will not be able to be carried out. Summary of the invention The embodiment of the invention provides a network television channel service implementation method and related equipment, and can implement an IMS-based IPTV channel service in a unicast manner.
  • An embodiment of the present invention provides a method for implementing a network television channel service, including:
  • An embodiment of the present invention provides a user equipment, including:
  • a metadata acquiring unit configured to acquire channel metadata that is sent by the network side; where the channel metadata includes channel type information;
  • a message generating unit configured to generate a session establishment request for joining a channel according to the channel type information in the channel metadata acquired by the metadata acquiring unit, where the session establishment request includes the channel identifier; if the channel type is multicast The channel, the generated session establishment request includes the SDP information of the multicast channel, and if the channel type is a unicast channel, the generated session establishment request includes the SDP information of the unicast channel.
  • An embodiment of the present invention provides a metadata server, including:
  • a receiving unit configured to receive a channel metadata acquisition request initiated by the user equipment
  • a metadata storage unit configured to store channel metadata, where the stored channel metadata includes a type identifier of the channel
  • a metadata acquiring unit configured to acquire channel metadata stored by the metadata storage unit according to an acquisition request of a user received by the receiving unit
  • a sending unit configured to send the channel metadata that is obtained by the metadata acquiring unit, including the channel type identifier, to the user equipment.
  • the embodiment of the invention provides a service control function device, including:
  • a receiving unit configured to receive a session establishment request sent by the user equipment to join the channel
  • a channel identifying unit configured to identify a type of the channel
  • a notification unit configured to: when the channel identification unit identifies that the type of the channel requested by the user equipment to join is a unicast channel, notify the media server to group according to the corresponding multicast stream address of the channel The broadcast stream is converted to a unicast stream.
  • An embodiment of the present invention provides a media server, including:
  • a media control unit configured to receive a request for a service control function device, and establish a control connection with the user; and a media transmission unit, configured to convert the multicast stream into a unicast stream according to the address of the multicast stream under the control of the re-media control unit And playing the unicast stream to the user.
  • the unicast channel type is added to the existing IMS-based IPTV channel service, and the network side converts the multicast stream of the multicast channel into a unicast stream for the unicast channel, and then plays the content to the user, so that Operators can support IMS IPTV channel services without a large-scale network transformation, reducing the cost of service implementation.
  • FIG. 1 is a signaling flow diagram of a IMS-based IPTV channel service implemented by a prior art through multicast;
  • FIG. 2 is a flowchart of a method for implementing a network television channel service according to an embodiment of the present invention
  • FIG. 3 is a flowchart of a method for implementing a network television channel service according to Embodiment 2 of the present invention
  • FIG. 5 is a signaling flowchart of adding channel metadata in an embodiment of the present invention.
  • FIG. 6 is a signaling flowchart of a user initiating a channel session according to a channel type according to an embodiment of the present invention
  • FIG. 7 is a signaling flowchart of applying an IPTV channel service to an IMS according to an embodiment of the present invention
  • FIG. 8 is a third embodiment of the present invention. Flowchart of a method for sending a session request;
  • FIG. 9 is a flowchart of a method for transmitting four-channel metadata according to an embodiment of the present invention.
  • FIG. 10 is a flowchart of a method for processing a network television channel service according to Embodiment 5 of the present invention.
  • FIG. 11 is a schematic structural diagram of a sixth user equipment according to an embodiment of the present invention.
  • FIG. 12 is a schematic structural diagram of a user equipment according to Embodiment 7 of the present invention.
  • FIG. 13 is a schematic structural diagram of an eight-ary data server according to an embodiment of the present invention.
  • FIG. 14 is a schematic structural diagram of a service control function device according to Embodiment 9 of the present invention.
  • FIG. 15 is a schematic structural diagram of ten media servers according to an embodiment of the present invention.
  • Embodiment 1 A method for implementing a network television channel service, which is shown in FIG. 2, includes:
  • A1 receiving a session establishment request sent by the user equipment to join the channel
  • the session establishment request of the user in the embodiment of the present invention may be received by the service control function device on the network side or may be received by other devices.
  • the network element of the specific session establishment request route may refer to various conventional implementations, and does not constitute a limitation on the present invention. .
  • A2 identifying the type of the channel that the user requests to join, and if the type of the channel is a unicast channel, converting the multicast stream corresponding to the multicast address into a unicast stream according to the corresponding multicast stream address of the channel;
  • the unicast channel type is added to the existing IMS-based IPTV channel service, and the network side converts the multicast stream of the multicast channel into a unicast stream for the unicast channel, and then sends the unicast stream to the user.
  • the broadcast enables the operator to support the IPTV channel service of the IMS without requiring a large-scale network transformation, thereby reducing the cost of the service implementation.
  • Embodiment 2 A method for implementing a network television channel service, and a flowchart shown in FIG. 3 includes:
  • the service control function device receives the session establishment request sent by the user equipment to join the channel; the session establishment request includes the channel identifier; in the embodiment of the present invention, the channel identifier may be a channel number or other identifier that can be used to distinguish the channel.
  • the service control function device identifies the type of the channel that the user requests to join; if the channel type is a multicast channel, proceeding to step B3, if the channel type is a unicast channel, proceeding to step B4;
  • the embodiment of the present invention adds a unicast channel type.
  • a unicast channel For a unicast channel, a multicast channel is converted into a unicast stream to implement a service.
  • the specific service control function device can identify a channel type in multiple ways. The following examples illustrate:
  • the channel type information may be added to the session establishment request of the user equipment to request to join the channel, that is, the channel type is specified by the user, and the step of identifying the channel type that the user requests to join the channel includes:
  • the service control function device identifies the type of the channel based on the channel type information.
  • the specific channel type information may be expressed in various manners, such as: adding a channel type information flag bit in the session establishment request, and identifying the type of the channel according to the value of the flag bit, or simply performing the message format according to the session establishment request.
  • the distinction is as follows:
  • the SDP format information in the session establishment request sent by the user equipment is differentiated.
  • Manner 2 Add a channel identifier in a session establishment request for requesting to join a channel; and the step of identifying a channel type that the user requests to join the channel includes:
  • Identifying the type of the channel according to the channel identifier specifically, the channel metadata corresponding to the channel identifier acquired by the service control function device SCF from the metadata server; and identifying the type of the channel according to the channel metadata.
  • the step of obtaining the multicast stream address of the channel and converting the multicast stream corresponding to the multicast address into a unicast stream may be performed by the service control function device and the media server, including: B4, service control function The device sends a request message to the media server;
  • the media server converts the multicast stream address corresponding to the multicast stream address into a unicast stream according to the multicast stream address of the channel.
  • the session establishment request sent by the user equipment to the service control function device includes a multicast stream address, and when the service control function device sends a request message to the media server, the multicast stream address is sent to the media server.
  • the session establishment request sent by the user equipment to the service control function device includes a channel identifier, and the service control function device acquires channel metadata by interacting with the metadata server according to the channel identifier, and further obtains the multicast stream address in the channel metadata.
  • the request message is sent to the media server
  • the multicast stream address is sent to the media server together.
  • the session establishment request sent by the user equipment to the service control function device includes a channel identifier, and the service control function device sends the channel identifier to the media server when the request message is sent to the media server, and the media server interacts with the metadata server to obtain the channel. Identifies the corresponding multicast stream address.
  • the specific play unicast stream can be as follows:
  • the media server establishes a streaming media connection channel with the user equipment by implementing a RealTime Streaming Protocol (RTSP) protocol;
  • RTSP RealTime Streaming Protocol
  • the media connection channel of the bearer layer may be established between the media server and the user equipment by using the RTSP protocol, or subsequent control may be performed.
  • the media negotiation can be performed in the process of connecting the channels.
  • the media negotiation can be performed by using the SDP protocol.
  • the content of the negotiation can be the coding rate, the uplink and downlink ports, and so on.
  • the media server plays the unicast stream through the streaming connection channel.
  • the method may further include:
  • the media server receives the user equipment to send a control request; the media server performs time shift control on the played unicast stream according to the control request.
  • the specific time shift control can be pause play, or back.
  • the session between the user equipment and the media server may be ended, and the media connection channel may be released.
  • the specific one may be:
  • the user equipment sends a session request to the service control function device, where the request includes a channel identifier, and the service control function device identifies the channel as a unicast channel, and sends a session end request to the media server; the media server receives the session of the service control function device The request releases the streaming connection channel with the user device and ends the session.
  • the unicast stream is played by the media connection channel established between the media server and the user equipment.
  • the media stream can be implemented through the RTSP protocol session.
  • Time-shift control such as suspending and rewinding, provides users with more abundant services without increasing the cost of the business, and is close to the user's needs and enhances the user experience.
  • the content metadata may be requested from the system side.
  • the process for the UE to obtain channel metadata is as shown in FIG. 4, including:
  • the CI and the UE initiate a channel metadata acquisition request
  • the service switch function receives the channel element data request, checks the UE legality, and passes the request to the metadata server;
  • the metadata server transmits the channel metadata with the channel type to the UE; the channel metadata is forwarded through the SSF.
  • the channel metadata delivered by the metadata server extends the attributes of the channel type.
  • the channel metadata fragment sent by the server to the UE is as follows.
  • the Type attribute indicates the channel type, where CCTV1 is a multicast channel and CCTV2 is a unicast channel:
  • the channel metadata saved by the metadata server can be maintained or added by the maintenance personnel through the content management component (CMS) system and the metadata server, and the process of adding the channel metadata is taken as an example.
  • CMS content management component
  • the process is as shown in FIG. 5, including :
  • the maintenance personnel add a channel in the CMS system, specify the channel type (unicast channel or multicast channel) to fill in the channel multicast address; for the unicast channel, the multicast address is used for the media transmission function device of the subsequent media server (MDF) Media Delivery Function, MDF) receives the media stream;
  • MDF media Delivery Function
  • the CMS sends the channel metadata to the metadata server for storage
  • the metadata server returns a response after saving the channel
  • the maintenance personnel define a unicast channel through the media control function (MCF) of the media server through the CMS, and after receiving the play request of the unicast channel, the MCF coordinates the MDF to receive according to the multicast address.
  • MCF media control function
  • MCF returns the unicast channel definition result to the CMS
  • the channel metadata fragment below expands the CHANNELTYPE field to indicate the channel type: CHANNELID INTEGER not null,
  • CHANNELTYPE INTEGER default (1)
  • the process of the user initiating the channel session according to the channel type is as shown in FIG. 6, which includes: F1.
  • the user equipment UE
  • step F2 identifying that the channel is a multicast channel or a unicast channel; if it is a multicast channel, proceeding to step F3, if it is a unicast channel, proceeding to step F4;
  • F3 for the multicast channel, construct a multicast channel SDP, and initiate a multicast channel Invite request;
  • the UE constructs a unicast channel request SDP, and initiates a unicast channel Invite request.
  • the UE constructs a unicast channel request SDP, and initiates a unicast channel Invite request:
  • the Reqeust-URI requested by the Invite is set to the public service flag of the channel; the To header field setting is the same as the Reqeust-URI; the public service flag is IPTV_BC_SERVICE@XX.com;
  • the From header field is set to the user IP Multimedia Public Identity (IMPU), such as 16172024202@XX.com; the Content-Type is set to application/sdp; the message body is the unicast channel SDP, which contains the m line of the media control channel. , m line of media transmission channel and channel service package information, for example:
  • m application 9 TCP iptv_rtsp ⁇ Required when negotiating the RTSP control channel.
  • the M line indicates that the media is an RTSP control channel, the media type is application, the transmission type is TCP, and the media format is iptv_rtsp (see refer RFC2327).
  • m ⁇ video 7720 RTP/AVP 33 ⁇ m line indicates the content of the media transmission channel, media transmission type 33 is MP2 over RTP; 7720 is the UDP port used by the UE to receive the stream.
  • the IMS Core forwards the message to the RACS, and performs unicast resource reservation;
  • the IMS Core forwards the Invite message to the SCF;
  • SCF automatically adapts the multicast/unicast channel:
  • the SCF receives the Invite request of the channel, and identifies the channel as a multicast channel according to the channel type identifier in the channel metadata (channel metadata obtained by the SCF from the metadata server).
  • Unicast channel for the multicast channel, the detailed process of the channel processing refers to the prior art process; for the unicast channel, after the SCF requests the authorization check to pass, the MCF is selected for the UE;
  • the Reqeust-URI of the Invite request is set to the SIP URL of the MCF such as MCF1 @XX.com;
  • the To header field is the requested channel identifier; the Content-Type and the message body SDP remain unchanged;
  • the G6-G8 and the MCF After receiving the Invite request from the BC service, the G6-G8 and the MCF select the MDF and respond to the SCF with the SDP response carried by the 200 OK.
  • TCP iptv_rtsp IM line indicates that the media is RTSP control channel, MCF server side port 554
  • a sendonly //Instructs the MCF to be the sender of the media.
  • the G9-G11 and the SCF After receiving the 200 OK response of the MCF, the G9-G11 and the SCF send a 200 OK to carry the updated SDP response to the UE;
  • the UE receives 200 OK, and sends back an ACK response;
  • the UE completes the RTSP interaction with the MCF according to the RTSP address and the session identifier in the 200 OK message SDP, and obtains the channel unicast stream.
  • the UE can directly interact with the MCF through the RTSP protocol to implement time shift control of the channel, such as performing back-off and positioning to play at a certain time point, or suspending playback.
  • the MCF that currently sends a unicast channel stream to the UE may not have a time shift function.
  • the MCF receives the unicast channel time shift handover request of the UE, it first determines whether the MDF currently serving as the user server supports the time shift function. If yes, the MTF sends a time-shifted request directly to the MDF. If the current MDF of the user server does not support the time shift function, the MCF selects an MDF that supports the time shift for the UE, and notifies the MDF to send the unicast stream to the user.
  • the notification may include time shift information indicating from which point in time the playback starts, the process being controlled by the MCF and transparent to the UE.
  • the UE After the unicast channel is played or the user voluntarily quits, the UE needs to send a BYE request to end the conference. If the SCF receives the user's BYE request and recognizes that the channel is a unicast channel, it sends a BYE to the MCF to end the unicast session.
  • This application example describes the IPTV channel service provided by the IMS subsystem, and the signaling between the devices uses the SIP message.
  • the difference between the application example and the application example 1 is that the application example 1 carries the SDP in the interaction signaling of the RTSP control session. The information directly completes the establishment of the media connection channel.
  • the RTSP session is established first, and the media connection channel is established through the RTSP message.
  • the application unicast channel control flow is separately established from the media stream, the process and unicast are established.
  • the channel control flow is consistent with the process of establishing the media stream at the same time.
  • the difference is that the Invite message SDP sent by the UE to the SCF carries only the parameters negotiated by the media control channel, does not carry the parameters of the media transmission channel, and negotiates the transmission plane. Will be completed by RTSP message.
  • the SDP sent by the SCF to the MCF includes the m line of the media control channel and the channel service packet information, as follows:
  • the SDP in the 200 OK message that the MCF responds to the UE includes the m line and channel service packet information of the media control channel, as follows:
  • the method of establishing the media transmission channel and updating the media session through the RTSP description message (DESRIBE), the establishment of the message (SETUP), and the update of the media session can be implemented in the existing conventional manner, and are not described herein.
  • the user equipment when performing time shift switching, the user equipment only needs to send a request directly to the media server through the RTSP protocol, and the media server receives the user's control to perform a time shift operation, but if the user equipment has not performed
  • the time-shift authority of the channel is authenticated.
  • the process of switching the UE unicast channel to the time shift can trigger the privilege authentication by resending the relNVITE request by the user equipment.
  • the process of the unicast channel control flow is consistent with the process of establishing the media stream at the same time.
  • the difference is that the original SDP of the Invite message body sent by the UE to the SCF is removed.
  • Channel service package information; an XML message body called IPTVActionDataCommand named S witchToTM has been added.
  • the XML message body format can be found in the existing specification.
  • the unicast channel time-shifting switches the rernvite request, and the request message includes XML and SDP.
  • the SDP is also slightly different because the control channel and the media connection channel are simultaneously established and separately established, and the control channel and the media connection channel are simultaneously established.
  • the relnvite message body is as follows: —scfboundary
  • Embodiment 3 A method for sending a session request, the flowchart is as shown in FIG. 8, and includes:
  • the channel metadata includes a channel type letter Interest rate
  • H2 Generate a session establishment request for joining the channel according to the channel type information in the channel metadata acquired by the metadata acquiring unit.
  • the session establishment request includes the channel identifier; if the channel type is a multicast channel, the generated session establishment request includes SDP information of the multicast channel, if the channel type is a single Broadcast channel, the generated session establishment request contains SDP information of the unicast channel.
  • the session establishment request generated by the message generating unit includes a channel identifier or the channel type information, so that the network side identifies the type of the channel according to the channel identifier or the channel type information.
  • the channel type in the channel metadata is obtained, and different session establishment requests are sent according to different channel types, so that the network side can perform different processing according to different session requests, and the network side processes the unicast channel. provide support.
  • Embodiment 4 A channel metadata sending method, which is shown in FIG. 9 and includes:
  • the channel metadata includes a type identifier of a channel
  • the obtained channel metadata including the channel type identifier is sent to the user equipment.
  • the channel metadata stored by the metadata storage unit further includes a multicast address of the channel, and if the channel type is a multicast channel, the multicast address is used by the user equipment to receive the multicast stream; The channel type is a unicast channel, and the multicast address is used by the media server to obtain a multicast stream and convert the multicast stream into a unicast stream.
  • the channel metadata is extended, so that the network side can identify the channel type according to the channel metadata and perform differential processing.
  • Embodiment 5 A network television channel service processing method, as shown in FIG. 10, the flowchart includes: S1, receiving a session establishment request sent by a user equipment and requesting to join a channel;
  • S2 identifying the type of the channel; if the type of the channel that the user equipment requests to join is a unicast channel, notifying the media server to convert the multicast stream into a unicast stream according to the corresponding multicast stream address of the channel.
  • the user equipment plays.
  • the network television channel service processing method provided by this embodiment is adopted in an existing IMS-based service.
  • the unicast channel type is added to the IPTV channel service.
  • the network side converts the multicast stream of the multicast channel into a unicast stream and then plays it to the user, so that the operator does not need a large-scale network transformation.
  • Support for IMS IPTV channel services reduces the cost of service implementation.
  • the embodiment of the present invention further provides a user equipment, a metadata server, and a media server, which implement the foregoing method, which are described in detail below.
  • Embodiment 6 A user equipment 800, a schematic structural diagram is shown in FIG. 11, and includes:
  • the metadata obtaining unit 810 is configured to obtain channel metadata that is sent by the network side, and the channel metadata includes channel type information.
  • the message generating unit 820 is configured to generate a session establishment request for joining the channel according to the channel type information in the channel metadata acquired by the metadata acquiring unit 810, where the session establishment request includes a channel identifier; if the channel type is a multicast channel, the generated session is generated. The SDP information requesting the multicast channel is established. If the channel type is a unicast channel, the generated session establishment request includes the SDP information of the unicast channel.
  • the session establishment request generated by the message generating unit may include channel identifier or channel type information, so that the network side identifies the type of the channel according to the channel identifier or the channel type information.
  • Embodiment 7 is a schematic diagram of a user equipment, as shown in FIG. 12, in this embodiment, a playback unit 830 and a control unit 840 are added to the third embodiment;
  • the playing unit 830 is configured to establish a media connection channel with the network side, and receive the unicast media stream through the established media connection channel.
  • the control unit 840 is configured to send a time shift control request to the media server, and perform time shift control on the unicast media stream received by the media connection channel.
  • Embodiment 8 is a metadata server 900.
  • the structure is as shown in FIG. 13 , and includes: a receiving unit 910, configured to receive a channel metadata acquisition request initiated by a user equipment, and a metadata storage unit 920, configured to store channel metadata.
  • the stored channel metadata includes a type identifier of the channel;
  • the metadata obtaining unit 930 is configured to obtain the number of elements according to the acquisition request of the user received by the receiving unit. According to the channel metadata stored by the storage unit;
  • the sending unit 940 is configured to send the channel metadata including the channel type identifier acquired by the metadata acquiring unit to the user equipment.
  • the channel metadata stored by the metadata storage unit 920 may further include a multicast address of the channel. If the channel type is a multicast channel, the multicast address is used by the user equipment to receive the multicast stream; The type is a unicast channel, and the multicast address is used by the media server to obtain a multicast stream and convert the multicast stream into a unicast stream.
  • Embodiment 9 is a service control function device 1000.
  • the structure is as shown in FIG. 14.
  • the method includes: a receiving unit 1010, configured to receive a session establishment request sent by a user equipment to join a channel, and a channel identification unit 1020, configured to identify Type of channel;
  • the channel identification unit 1020 can identify the channel type in multiple manners.
  • the receiving unit 1010 may receive the channel type information in the session establishment request sent by the UE, or may be the service control function.
  • the device obtains the type of the channel according to the channel identifier in the session establishment request received by the receiving unit, and the channel identification unit may include: a metadata request unit 1021, configured to request metadata from the metadata server;
  • the type identifying unit 1022 is configured to obtain channel metadata returned by the metadata server, and determine a channel type of the channel according to the type identifier in the channel metadata.
  • the notification unit 1030 is configured to: when the channel identification unit identifies that the type of the channel requested by the user equipment to join is a unicast channel, notify the media server to convert the multicast stream into a unicast stream according to the corresponding multicast stream address of the channel.
  • Embodiment 10 A media server 1100, a schematic structural diagram is shown in FIG. 15, including: a media control unit 1110, configured to receive a request of a service control function device, and establish a control connection with a user;
  • the media transmission unit 1120 is configured to convert the multicast stream into a unicast stream according to the address of the multicast stream under the control of the re-media control unit, and play the unicast stream to the user.
  • the media control unit may be further configured to receive a control request of the user, and control the unicast stream transmitted by the media transmission unit according to the control request of the user.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

网络电视频道业务实现方法和相关设备 技术械
本发明涉及通信技术领域，具体涉及网络电视频道业务实现方法和相关设 备。
背景技术
交互式网络电视（Internet Protocol Television, IPTV )是一种7？载在网际 协议（Internet Protocol, IP ) 网络之上， 提供电视、 视频、 语音、 文本、 图像、 数据等业务的多媒体系统。伴随着网络不断进步和业务不断丰富， 多媒体与通 信融合、 固定与移动融合、 互联网与电信融合是必然趋势。
IP多媒体系统（ IP Multimedia Subsystem, IMS )是实现 IP网络与通信业务 融合的统一系统架构， 现有的基于 IMS的 IPTV频道业务通过组播方案实现，业 务流程如图 1所示：
1、 用户设备 ( User Equipment, UE )接入基于 IMS的 IPTV系统后， 发起 组播频道会话建立请求给 IMS核心网 （IMS Core ), 该请求可以是基于 SIP协议 的 Invite消息此请求消息体带有组播会话描述（SDP)信息；
2、 IMS Core转发所述 Invite请求给资源和准入控制子系统（Resource and Admission Control Subsystem , RACS ), 完成资源预留和准入控制；
3、 IMS Core转发所述 Invite请求给业务控制功能设备（Service Control Function ， SCF );
4-5、 SCF对 Invite请求进行授权检查， 通过后直接发送确认消息（ 200 OK ) 给 IMS Core;
6、 IMS Core转发 200 OK响应给 RACS, 完成资源提交；
7、 IMS Core转发 200 OK响应给 UE;
8-9、 UE发送最终确认消息（ACK )给 SCF;
10-11、 频道会话建立， UE直接加入组播频道接收频道数据流；
现有技术中， 基于 IMS的 IPTV频道业务， 用户设备（UE )通过加入组 播频道获取频道数据流，这就要求网络必须支持全网组播， 如果部分网络或设 备只支持单播，不支持组播，那么将无法开展上述流程描述的 IPTV频道业务。 发明内容 本发明实施例提供网络电视频道业务实现方法和相关设备，可以通过单播 方式实现基于 IMS的 IPTV频道业务。
本发明实施例提供一种网络电视频道业务实现方法， 包括：
接收用户设备发送的请求加入频道的会话建立请求；
识别所述用户请求加入频道的频道类型， 若所述频道的类型为单播频道， 则根据所述频道的对应的组播流地址，将所述组播地址对应的组播流转化为单 播流；
向所述用户设备播放所述单播流。
本发明实施例提供一种用户设备， 包括：
元数据获取单元， 用于获取网络侧下发的频道元数据； 所述频道元数据中 包含频道类型信息；
消息生成单元，用于根据所述元数据获取单元获取的频道元数据中的频道 类型信息生成加入频道的会话建立请求， 所述会话建立请求包含所述频道标 识； 若所述频道类型为組播频道， 则生成的会话建立请求包含组播频道的 SDP 信息， 若所述频道类型为单播频道， 则生成的会话建立请求包含单播频道的 SDP信息。
本发明实施例提供一种元数据服务器， 包括：
接收单元， 用于接收用户设备发起的频道元数据获取请求；
元数据存储单元， 用于存储频道元数据， 所述存储的频道元数据包括频道 的类型标识；
元数据获取单元，用于根据所述接收单元接收的用户的获取请求获取所述 元数据存储单元存储的频道元数据；
下发单元，用于将所述元数据获取单元获取的包括频道类型标识的频道元数据 下发给用户设备。
本发明实施例提供一种业务控制功能设备， 包括：
接收单元， 用于接收用户设备发送的请求加入频道的会话建立请求； 频道识别单元， 用于识别频道的类型；
通知单元，用于在所述频道识别单元识别所述用户设备请求加入的频道的 类型为单播频道时， 通知媒体服务器根据所述频道的对应的组播流地址，将组 播流转换为单播流。
本发明实施例提供一种媒体服务器， 包括：
媒体控制单元，用于接收业务控制功能设备的请求，与用户建立控制连接； 媒体传输单元， 用于再媒体控制单元的控制下， 根据组播流的地址， 将組 播流转化为单播流， 并向用户播放所述单播流。
本发明实施例采用在已有的基于 IMS的 IPTV频道业务中增加单播频道类 型， 网络侧对于单播频道， 先将组播频道的组播流转化为单播流， 再向用户播 放，使得运营商无需大范围的网络改造， 即可实现对 IMS的 IPTV频道业务的 支持， 降低了业务实现的成本。
附图说明
图 1是先有技术通过组播方式实现基于 IMS的 IPTV频道业务的信令流程 图；
图 2是本发明实施例一网络电视频道业务实现方法的流程图；
图 3是本发明实施例二网络电视频道业务实现方法的流程图；
囹 4是本发明实施例中用户设备获取频道元数据的信令流程图；
图 5是本发明实施例中新增频道元数据的信令流程图；
图 6是本发明实施例中用户根据频道类型发起频道会话的信令流程图； 图 7是本发明实施例应用到 IMS中提供 IPTV频道业务的信令流程图； 图 8是本发明实施例三会话请求发送方法的流程图；
图 9是本发明实施例四频道元数据发送方法的流程图；
图 10是本发明实施例五网络电视频道业务处理方法的流程图；
图 11是本发明实施例六用户设备的结构示意图；
图 12是本发明实施例七用户设备的结构示意图；
图 13是本发明实施例八元数据服务器的结构示意图；
图 14是本发明实施例九业务控制功能设备的结构示意图；
图 15是本发明实施例十媒体服务器的结构示意图。
具体实施方式
本发明实施例提供网络电视频道业务实现方法和相关设备，以下分别进行 详细说明。 实施例一、 一种网络电视频道业务实现方法， 流程图如图 2所示， 包括：
A1， 接收用户设备发送的请求加入频道的会话建立请求；
本发明实施例中接受用户的会话建立请求可以由网络侧的业务控制功能 设备接收也可以由其他设备接收，具体的会话建立请求路由的网元可以参考多 种常规实现， 不构成对本发明的限制。
A2, 识别用户请求加入的频道的类型， 若频道的类型为单播频道， 则根 据频道的对应的組播流地址， 将組播地址对应的组播流转化为单播流；
A3 , 向用户设备播放单播流。
本发明实施例一中，采用在已有的基于 IMS的 IPTV频道业务中增加单播频 道类型， 网络侧对于单播频道， 先将组播频道的组播流转化为单播流， 再向用 户播放，使得运营商无需大范围的网络改造， 即可实现对 IMS的 IPTV频道业务 的支持， 降低了业务实现的成本。
实施例二、 一种网络电视频道业务实现方法， 流程图如图 3所示， 包括：
B1， 业务控制功能设备接收用户设备发送的请求加入频道的会话建立请 求； 会话建立请求包含频道标识； 本发明实施例中， 所述频道标识可以是频道 号或者其他可以用于区分频道的标识。
B2， 业务控制功能设备识别用户请求加入的频道的类型； 若频道类型为 组播频道， 则继续步骤 B3， 若频道类型为单播频道， 则继续步骤 B4;
本发明实施例增加了单播频道类型，对于单播频道， 采用将组播频道的组 播流转化为单播流的方式实现服务，具体业务控制功能设备识别频道类型的方 式可以有多种， 下面举例说明：
方式一、本发明实施例中可以在用户设备请求加入频道的会话建立请求中 增加频道类型信息， 即频道类型由用户发送的请求指定， 识别用户请求加入频 道的频道类型的步骤包括：
业务控制功能设备根据频道类型信息识别频道的类型。
具体的频道类型信息可以采用多种方式表示，如： 在会话建立请求中增加 频道类型信息标志位，根据标志位的值用于标识频道的类型，也可以简单的根 据会话建立请求的消息格式进行区分，如： 根据用户设备发送的会话建立请求 中的 SDP格式信息进行区分。 方式二、 在请求加入频道的会话建立请求中增加频道标识； 识别用户请求加入频道的频道类型的步骤包括：
根据频道标识识别频道的类型， 具体的， 业务控制功能设备 SCF从元数据 服务器获取的频道标识对应的频道元数据； 并根据频道元数据识别频道的类 型。
B3 , 采用常规的組播方式为用户设备提供 IPTV频道业务。
本实施例中， 获取频道的组播流地址， 并将组播地址对应的组播流转化为 单播流的步骤可以由业务控制功能设备和媒体服务器配合完成， 具体包括： B4, 业务控制功能设备向媒体服务器发送请求消息；
B5 , 媒体服务器艮据频道的組播流地址， 并将组播流地址对应的组播流 转化为单播流。
媒体服务器获取频道对应的組播地址的方式可以有多种，下面举例进行说 明：
方式一、用户设备向业务控制功能设备发送的会话建立请求中包含组播流 地址， 业务控制功能设备向媒体服务器发送请求消息时， 将组播流地址发送给 媒体服务器。
方式二、用户设备向业务控制功能设备发送的会话建立请求中包含频道标 识， 业务控制功能设备根据频道标识与元数据服务器交互获取频道元数据， 并 进一步获取频道元数据中的组播流地址； 在向媒体服务器发送请求消息时，将 组播流地址一起发送给媒体服务器。
方式三、用户设备向业务控制功能设备发送的会话建立请求中包含频道标 识， 业务控制功能设备在向媒体服务器发送请求消息时， 将频道标识发送给媒 体服务器， 媒体服务器与元数据服务器交互获取频道标识对应的組播流地址。
B6, 向用户设备播放单播流。
具体的播放单播流可以通过以下方式：
媒体服务器通过实施流协议（RealTime Streaming Protocol, RTSP )协议 建立与用户设备的流媒体连接通道；
本实施例中， 媒体服务器和用户设备之间可以通过 RTSP协议建立承载层 的媒体连接通道， 或者进行后续的控制。 可以理解在通过 RTSP协议建立媒体 连接通道的过程中可以进行媒体协商， 媒体协商可以采用 SDP协议进行， 协商 的内容可以是编码速率、 上下行端口等信息。
媒体服务器通过流媒体连接通道播放单播流。
本实施例中， 在步骤 B6之后还可以包括：
媒体服务器接收用户设备发送控制请求；媒体服务器根据控制请求，对播 放的单播流进行时移控制。 具体的时移控制可以是暂停播放， 或者后退等。
本实施例中，单播流播放结束或者用户主动退出， 则可以结束用户设备与 媒体服务器的会话， 释放媒体连接通道， 具体的可以是：
用户设备向业务控制功能设备发送会话请求，请求中包含频道标识， 业务 控制功能设备识別该频道为单播频道， 则发送会话结束请求给媒体服务器； 媒体服务器收到业务控制功能设备的会话结束请求，则释放与用户设备的 流媒体连接通道， 结束会话。
本发明实施例二中，由于采用的媒体服务器与用户设备之间单独建立的媒 体连接通道播放单播流， 相对于现有技术中的组播方式， 可以实现通过 RTSP 协议会话实现对媒体流的时移控制， 如暂停、后退等， 在不增加业务成本的基 础上为用户提供更加丰富的服务， 贴近用户需求， 提升用户体验。
本发明实施例中， UE使用业务前， 可以向系统侧请求内容元数据。
UE获取频道元数据的流程如图 4所示， 包括：
CI、 UE发起频道元数据获取请求；
C2、 业务交换功能设备（Service switch Function, SSF )接收到频道元数 据请求， 校验 UE合法性， 校验通过则转发请求到元数据服务器；
C3-C4,元数据服务器将带有频道类型的频道元数据发送到 UE; 频道元数 据通过 SSF转发。
可以理解， 元数据服务器下发的频道元数据扩展了频道类型的属性。 元素据服务器下发给 UE的频道元数据片断举例如下， Type属性表示频道 类型,其中 CCTV1是组播频道， CCTV2是单播频道：
<ChannelList>
<Channel ID=1 Index=l Name=CCTVl Rating=18 Preview=l IsTSTV=0 Bitrate=2000 Type=l IP=224.24.24.24 Port=8082 /> <Channel ID=2 Index=2 Name=CCTV2 Rating=18 Preview=0 IsTSTV=l
Bitrate=2000 Type=2 />
</ChannelList>
元数据服务器保存的频道元数据可以由维护人员通过内容管理部件 ( CMS )系统与元数据服务器交互进行维护或新增，以新增频道元数据的过程 为例， 流程如图 5所示， 包括：
D1 , 维护人员在 CMS系统中新增频道， 指定频道类型 （单播频道或組播 频道）填写频道组播地址； 对于单播频道， 组播地址用于后续媒体服务器的媒 体传输功能设备 ( MDF Media Delivery Function, MDF )接收媒体流；
D2, CMS将频道元数据发送给元数据服务器保存；
D3、 元数据服务器保存频道后返回响应；
D4、 对于单播频道， 维护人员通过 CMS在媒体服务器的媒体控制功能设 备（ Media Control Function， MCF ) 定义单播频道， MCF在收到单播频道的 播放请求后， 协调 MDF根据组播地址接收频道组播流， 转换成单播；
D5 , MCF返回单播频道定义结果给 CMS;
如下频道元数据片断举例， 扩展出 CHANNELTYPE字段表示频道类型： CHANNELID INTEGER not null,
FOREIGNSN VARCHAR2(128) not null,
CHANNELINDEX INTEGER not null,
CHANNELNAME1 VARCHAR2(384) not null,
CHANNELNAME2 VARCHAR2(384),
RATINGID INTEGER,
SPID VARCHAR2(36),
PREVIEW INTEGER default (1 )，
BITRATE INTEGER default (2000)，
IP VARCHAR2(15),
PORT INTEGER,
ISTSTV INTEGER,
CHANNELTYPE INTEGER default (1), 用户根据频道类型发起频道会话的过程如图 6所示， 包括： F1 , 用户触发频道播放时， 用户设备 ( UE )获取频道元数据中频道类型 标识；
F2, 识别此频道是組播频道或单播频道； 若是組播频道， 则继续步骤 F3 , 若是单播频道则继续步骤 F4;
F3, 对于组播频道， 构造组播频道 SDP, 发起組播频道 Invite请求；
F4, 对于单播频道， UE构造单播频道请求 SDP, 发起单播频道 Invite请 求。
下面结合应用场景， 提供本发明实施例二的具体应用例。
应用例一：
本应用例以 IMS提供 IPTV频道业务进行描述， 设备之间的信令采用 SIP消 息， 具体流程如图 7所示， 包括：
Gl、 UE识别此频道是单播频道后， UE构造单播频道请求 SDP， 发起单播 频道 Invite请求：
其中， Invite请求的 Reqeust-URI设置为频道的公共服务标志； To头域设置 与 Reqeust-URI相同； 公共服务标志如 IPTV_BC_SERVICE@XX.com;
From头域设置为用户 IP多媒体公共标识 ( IP Multimedia Public Identity, IMPU ), 如 16172024202@XX.com; Content-Type设置为 application/sdp; 消息 体为单播频道 SDP， 包含媒体控制通道的 m行、 媒体传输通道的 m行和频道服 务包信息， 举例如下：
v=0
o=- 3434049036 0 IN IP4 10.170.15.105
s=Unicast BC initiation
i=this is a typical initial Unicast BC SIP SDP Invite example!
t=0 0
m=application 9 TCP iptv_rtsp〃协商 RTSP控制信道时必选。 M行指示 媒体为 RTSP控制通道， 媒体类型为 application, 传输类型为 TCP,媒体格式 为 iptv_rtsp (参见 refer RFC2327 )
c=IN IP4 10.170.15.105〃指示连接的 UE的 IP地址 a=connection： new
a=fmtp:iptv_rtsp 1 / RTSP版本号 1
a-setup: active
m^video 7720 RTP/AVP 33 〃m行指示媒体传输通道的内容， 媒体传输 类型 33为 MP2 over RTP; 7720为 UE接收流使用的 UDP端口
c=IN IP4 10.170.15.105〃指示连接的 UE的 IP地址
b=AS:2000 //节目的使用带宽
a=bc_service:sip:hwl @XX.COm //UE要打开的频道为 hwl
a=bc_service_package: l 〃频道 hwl所属于的服务包为 1 , 授权使用 a=recvonly〃仅接收
G2、 IMS Core转发消息给 RACS, 进行单播资源预留；
G3、 资源预留完成后， IMS Core转发 Invite消息给 SCF;
G4、 SCF自动适配组播 /单播频道： SCF接收到频道的 Invite请求， 根据频 道元数据 ( SCF从元数据服务器获取的频道元数据 ) 中频道类型标识， 识别此 频道是组播频道或单播频道； 对于组播频道， 频道处理详细流程参考现有技术 流程； 对于单播频道， SCF请求授权检查通过后， 为 UE选择 MCF;
G5 , 采用背靠背代理（B2BUA )方式发起 Invite请求给 MCF:
其中， Invite请求的 Reqeust-URI设置为 MCF的 SIP URL如 MCF1 @XX.com;
To头域为请求的频道标识； Content-Type与消息体 SDP保持不变；
G6-G8、 MCF接收到 BC服务的 Invite请求后，选择 MDF,向 SCF响应 200 OK 携带的 SDP应答， SDP中携带媒体控制通道的 m行、 媒体传输通道的 m行： v=0
o=MCF 1073742166 1073742166 IN IP4 10.70.1.80
s=Sip Call
t=0 0
m=application 554 TCP iptv_rtsp IM行指示媒体为 RTSP控制通道， MCF ^^务器侧端口 554
c=IN IP4 10.70.1.80
a=setup:passive a=connection： new a=fmtp:iptv_rtsp h-uri=rtsp://10.70.1.80/hwl 〃MCF 在返回的 UE用于发起 RTSP播放的 URI地址。
a-fmtp:iptv_rtsp h-session:02300311 / MCF在创建 RTSP会话后返回的 RTSP session ID
a=fmtp:iptv_rtsp h -of f set： clock=20081030T 191625Z〃时移左窗口边界 a=fmtp:iptv_rtsp 1
m=video 288 RTP/AVP 33〃m行指示媒体传输通道的内容，媒体传输类型 33为 MP2 over RTP; 288为服务器发送流使用的 UDP端口
c=IN IP4 10.70.0.64 〃服务器侧的 IP地址
b=AS:2000
a =b c_ser vice： sip : h w 1 @huawei.com
a=bc_service_package: 1
a=sendonly //指示 MCF为媒体的发送方。
G9-G11、 SCF接收到 MCF的 200 OK响应后， 发送 200 OK携带更新后 的 SDP响应给 UE;
Gl 0-G11、 IMS Core转发 200 OK给 RACS提交资源预留， 并将消息转发
UE;
G12-G15 , UE收到 200 OK, 回送 ACK响应；
G16-G17, UE根据 200OK消息 SDP中的 RTSP地址和会话标识， 完成与 MCF的 RTSP交互， 获取频道单播流。
本应用例中， UE可以直接通过 RTSP协议与 MCF交互实现频道的时移控 制， 如执行后退及定位到某时间点播放， 或者暂停播放等操作。
有一种情况，当前给 UE发送单播频道流的 MDF上可能没有启动时移功能， 那么 MCF接收到 UE的单播频道时移切换请求时， 先判断当前为用户服务器的 MDF是否支持时移功能， 若支持， 则直接向 MDF发送时移切换请求， 如果当 前为用户服务器的 MDF不支持时移功能， 那么 MCF为 UE选择一个支持时移的 MDF, 并通知该 MDF向用户发送单播流， 该通知中可以包含指示从哪一个时 间点开始播放的时移信息， 该过程由 MCF实现控制， 对 UE透明。
单播频道的播放结束或用户主动退出后， UE需要发送 BYE请求结束会 话， SCF收到用户的 BYE请求，识別此频道为单播频道，则发送 BYE给 MCF 结束单播会话。
应用例二、
本应用例以 IMS子系统提供 IPTV频道业务进行描述，设备之间的信令采用 SIP消息， 本应用例与应用例一的区別在于， 应用例一在建立 RTSP控制会话的 交互信令中携带 SDP信息， 直接完成媒体连接通道的建立， 应用例二中， 采用 先建立 RTSP会话， 在通过 RTSP消息建立媒体连接通道， 本应用例单播频道控 制流与媒体流分开建立时，其流程与单播频道控制流与媒体流同时建立方式的 流程一致， 参见图五， 区别在于 UE发送到 SCF的 Invite消息 SDP中只携带了媒 体控制通道协商的参数， 不携带媒体传输通道的参数， 传输面的协商将通过 RTSP消息完成。
SCF向 MCF发送的 Invite请求中 UE的 SDP包含媒体控制通道的 m行和频道 服务包信息， 举例如下：
v=0
o=- 3434049036 0 IN IP4 10.170.15.105
s=Unicast BC initiation
i=this is a typical initial Unicast BC SIP SDP Invite example!
t=0 0
m-application 9 TCP iptv_rtsp
c=IN IP4 10.170.15.105
a=connection： new
a=fmtp:iptv_rtsp 1
a=setup : active
a =b c_ser vice： sip : hw 1 @huawei.com
a=bc_service_package: 1
a=recvonly
MCF向 UE响应的 200 OK消息中的 SDP包含媒体控制通道的 m行和频 道服务包信息， 举例如下：
v=0 o=- 3434049036 0 IN IP4 10.170.15.105
s=Unicast BC initiation
i-this is a typical initial Unicast BC SIP SDP Invite example!
t=0 0
m=application 554 TCP iptv_rtsp
c=IN IP4 10.70丄 80
a=setup :passive
a=connection： new
a=fmtp:iptv_rtsp h-uri=rtsp://10.70.1.80/hwl
a=fmtp:iptv_rtsp h-session： 02300311
a=fmtp:iptv_rtsp 1
a =b c_ser vice： sip : hw 1 @huawei.com
a=bc_service_package: 1
a=sendonly
建立 RTSP媒体控制通道后， 通过 RTSP的描述消息（DESRIBE )、 建立 消息（ SETUP )建立媒体传输通道的方法和更新媒体会话可以采用现有的常规 方式实现， 不在赘述。
上述应用例一和应用例二中，在进行时移切换时，用户设备只需通过 RTSP 协议直接向媒体服务器发送请求， 媒体服务器接收用户的控制进行时移操作， 但是， 如果用户设备没有进行过该频道的时移权限认证， 那么这种情况下， UE单播频道切换到时移的过程， 可以通过由用户设备重新发送 relNVITE请 求， 触发发权限认证， 下面描述 relNVITE流程和消息体格式。
单播频道时移切换（relnvite请求） 时， 其流程与单播频道控制流与媒体 流同时建立方式的流程一致， 参见图五， 区别在于 UE发送到 SCF的 Invite消 息体原有的 SDP去除了频道服务包信息； 新增了名为 S witchToTM，的 XML 消息体 IPTVActionDataCommand, XML消息体格式可以参见现有规范。
单播频道时移切换 relnvite请求， 请求消息包括 XML和 SDP, 其中 SDP 也因为控制通道与媒体连接通道同时建立和分开建立两种方式略有不同，以控 制通道和媒体连接通道同时建立方式举例的 relnvite消息体如下： —scfboundary
Content- Type: application/sdp
Content-Length: 360
v=0
o=- 3434049036 0 IN IP4 10.170.15.105
s=Unicast BC initiation
i=this is a typical initial Unicast BC SIP SDP Invite example! t=0 0
m=application 9 TCP iptv_rtsp
c=IN IP4 10.170.15.105
a=connection： new
a=fmtp:iptv_rtsp 1
a= setup: active
m=video 288 RTP/AVP 33
c=IN IP4 10.70.0.64
b=AS:2000
a=recvonly
-scfboundary
Content-Type: application/vnd.etsi.iptvcommand+xml
Content-Length: 571
<?xml version 1.0" encodings "UTF-8 " ?>
<IPTVActionDataCommand
xmlns=''urn:org:etsi:ngn:params:xml:ns:iptvactiondatacommand'' xmlns:bc="urn:org:etsi:ngn:params:xml:ns:iptvbcserviceactiondata" xmlns:co="urn:org:etsi:ngn:params:xml:ns:iptvcodserviceactiondata" xmlns:np="urn:org:etsi:ngn:params:xml:ns:iptvnpvrserviceactiondata' xmlns:xsi="http：〃 www.w3.org/2001/XMLSchema-instance">
<SwitchToTM>
<bc:IPTVBcActionData> <bc:BCBookmark>
<bc:BCServiceId>sip:hwl @hw.vz.us.com< bc:BCServiceId>
</bc:BCBookmark>
</bc:IPTVBcActionData>
</SwitchToTM>
</IPTVActionDataCommand>
响应消息 SDP, 包含媒体控制通道的 m行和频道服务包信息， 举例如下： v=0
o=- 3434049036 0 IN IP4 10.170.15.105
s=Unicast BC initiation
i=this is a typical initial Unicast BC SIP SDP Invite example!
t=0 0
m=application 554 TCP iptv_rtsp
c=IN IP4 10.70.1.80
a=setup:passive
a=connection： new
a=fmtp： iptv_rtsp h-uri=rtsp://10.70.1.80/hw 1
a=fmtp:iptv_rtsp h- session : 02300311
a-fmtp:iptv_rtsp h-offset:clock-20081030T 191625Z- a=f mtp： iptv_rtsp 1
m=video 288 RTP/AVP 33
c=IN IP4 10.70.0.64
b=AS:2000
a=sendonly
后续时移切换到频道， 因为已经完成了 UE的时移权限认证， 因此不再需 要重新发送 relnvite请求， UE可以采用应用例一中的方法直接通过 RTSP与 MCF交互即可实现对媒体流的控制。
实施例三、 一种会话请求发送方法， 流程图如图 8所示， 包括：
HI， 获取网络侧下发的频道元数据； 所述频道元数据中包含频道类型信 息；
H2 , 根据所述元数据获取单元获取的频道元数据中的频道类型信息生成 加入频道的会话建立请求。
可以理解， 本实施例中， 所述会话建立请求包含所述频道标识； 若所述频 道类型为组播频道， 则生成的会话建立请求包含组播频道的 SDP信息， 若所述 频道类型为单播频道， 则生成的会话建立请求包含单播频道的 SDP信息。
本发明实施例中，所述消息生成单元生成的会话建立请求中包含频道标识 或所述频道类型信息，以便于网络侧根据所述频道标识或所述频道类型信息识 别所述频道的类型。
本发明实施例三通过获得频道元数据中的频道类型，本根据不同的频道类 型发送不同的会话建立请求，使得网络侧可以根据不同的会话请求进行区別处 理， 为网络侧对单播频道的处理提供支持。
实施例四、 一种频道元数据发送方法， 流程图如图 9所示， 包括：
Ml， 接收用户设备发起的频道元数据获取请求；
M2, 根据所述接收单元接收的用户的获取请求获取所述元数据存储单元 存储的频道元数据； 所述频道元数据包括频道的类型标识；
M3 , 将所述获取的包括频道类型标识的频道元数据下发给用户设备。 本实施例中，所述元数据存储单元存储的频道元数据还包括频道的组播地 址， 若所述频道类型为組播频道， 则所述组播地址用于用户设备接收组播流； 若所述频道类型为单播频道， 则所述组播地址用于媒体服务器获取组播流， 并 将組播流转为单播流。
本实施例提供的频道元数据发送方法， 对频道元数据进行了扩展，使得网 络侧可以根据频道元数据识别频道类型， 并进行区别处理。
实施例五、 一种网络电视频道业务处理方法， 流程图如图 10所示， 包括： S1 , 接收用户设备发送的请求加入频道的会话建立请求；
S2,识别频道的类型；若所述用户设备请求加入的频道的类型为单播频道， 则通知媒体服务器根据所述频道的对应的组播流地址，将组播流转换为单播流 后向所述用户设备播放。
本实施例提供的网络电视频道业务处理方法， 采用在已有的基于 IMS的 IPTV频道业务中增加单播频道类型， 网络侧对于单播频道， 先将组播频道的 组播流转化为单播流， 再向用户播放， 使得运营商无需大范围的网络改造， 即 可实现对 IMS的 IPTV频道业务的支持， 降低了业务实现的成本。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步 骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读 存储介盾中， 存储介质可以包括： ROM, RAM, 磁盘或光盘等。
本发明实施例还提供实现上述方法的用户设备， 元数据服务器、 媒体服务器， 下面进行详细描述。
实施例六、 一种用户设备 800, 结构示意图如图 11所示， 包括：
元数据获取单元 810， 用于获取网络侧下发的频道元数据； 频道元数据中 包含频道类型信息；
消息生成单元 820，用于根据元数据获取单元 810获取的频道元数据中的频 道类型信息生成加入频道的会话建立请求，会话建立请求包含频道标识； 若频 道类型为组播频道， 则生成的会话建立请求包含组播频道的 SDP信息， 若频道 类型为单播频道， 则生成的会话建立请求包含单播频道的 SDP信息。
可以理解，本实施例中， 消息生成单元生成的会话建立请求中可以包含频 道标识或频道类型信息，以便于网络侧根据频道标识或频道类型信息识别频道 的类型。
实施例七、一种用户设备， 结构示意图如图 12所示， 本实施例中在实施例 三的基础上增加了播放单元 830和控制单元 840;
播放单元 830, 用于与网络侧建立媒体连接通道， 并通过建立的媒体连接 通道接收单播媒体流。
控制单元 840， 用于向媒体服务器发送时移控制请求， 对所述媒体连接通 道接收的单播媒体流进行时移控制。
实施例八、 一种元数据服务器 900, 结构示意图如图 13所示， 包括： 接收单元 910, 用于接收用户设备发起的频道元数据获取请求； 元数据存储单元 920, 用于存储频道元数据， 存储的频道元数据包括频道 的类型标识；
元数据获取单元 930, 用于根据接收单元接收的用户的获取请求获取元数 据存储单元存储的频道元数据；
下发单元 940, 用于将元数据获取单元获取的包括频道类型标识的频道元 数据下发给用户设备。
可以理解， 本实施例中， 元数据存储单元 920存储的频道元数据还可以包 括频道的组播地址， 若频道类型为组播频道， 则组播地址用于用户设备接收组 播流； 若频道类型为单播频道， 则组播地址用于媒体服务器获取组播流， 并将 组播流转为单播流。
实施例九、 一种业务控制功能设备 1000， 结构示意图如图 14所示， 包括： 接收单元 1010, 用于接收用户设备发送的请求加入频道的会话建立请求； 频道识别单元 1020, 用于识別频道的类型；
本实施例中， 频道识別单元 1020识別频道类型的方式可以有多种方式： 例如： 可以是接收单元 1010接收到 UE发送的会话建立请求中携带频道类 型信息，也可以是由业务控制功能设备根据接收单元接收的会话建立请求中的 频道标识与元数据服务器交互获得频道的类型，例如：频道识别单元可以包括： 元数据请求单元 1021 , 用于向元数据服务器请求元数据；
类型识别单元 1022,用于获取元数据服务器返回的频道元数据， 并根据频 道元数据内的类型标识确定频道的频道类型。
通知单元 1030，用于在频道识別单元识別用户设备请求加入的频道的类型 为单播频道时，通知媒体服务器根据频道的对应的组播流地址，将组播流转换 为单播流。
实施例十、 一种媒体服务器 1100, 结构示意图如图 15所示， 包括： 媒体控制单元 1110, 用于接收业务控制功能设备的请求， 与用户建立控制 连接；
媒体传输单元 1120， 用于再媒体控制单元的控制下， 根据组播流的地址， 将组播流转化为单播流， 并向用户播放单播流。
可以理解， 本实施例中， 媒体控制单元还可以用于接收用户的控制请求， 根据用户的控制请求对媒体传输单元传输的单播流进行控制。
以上对本发明实施例所提供的网络电视频道业务实现方法和相关设备进 行了详细介绍， 本文中应用了具体个例对本发明的原理及实施方式进行了阐 述， 以上实施例的说明只是用于帮助理解本发明的方法及其核心思想； 同时， 对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围 上均会有改变之处， 综上所述， 本说明书内容不应理解为对本发明的限制。

Claims

权 利 要 求
1、 一种网络电视频道业务实现方法， 其特征在于， 包括：
接收用户设备发送的请求加入频道的会话建立请求；
识别所述用户请求加入频道的频道类型， 若所述频道的类型为单播频道， 则根据所述频道的对应的组播流地址，将所述组播地址对应的组播流转化为单 播流；
向所述用户设备播放所述单播流。
2、 如权利要求 1所述的方法， 其特征在于， 所述接收用户设备发送的请求 加入频道的会话建立请求的步骤包括：
业务控制功能设备接收用户设备发送的请求加入频道的会话建立请求；所 述请求加入频道的会话建立请求中包含频道类型信息；
所述识别所述用户请求加入频道的频道类型的步骤包括：
业务控制功能设备根据所述频道类型信息识别所述频道的类型。
3、 如权利要求 1所述的方法， 其特征在于， 所述接收用户设备发送的请求 加入频道的会话建立请求的步骤包括：
业务控制功能设备接收用户设备发送的请求加入频道的会话建立请求；所 述请求加入频道的会话建立请求中包含频道标识；
所述根据所述频道标识识別所述频道的类型的步骤包括：
业务控制功能设备 SCF从元数据服务器获取的所述频道标识对应的频道 元数据；
根据所述频道元数据识别所述频道的类型。
4、 如权利要求 2或 3所述的方法， 其特征在于， 所述根据频道的组播流地 址， 将所述组播地址对应的组播流转化为单播流的步骤包括：
若所述频道的类型为单播频道，则业务控制功能设备向媒体服务器发送请 求消息；
媒体服务器根据所述频道的组播流地址， 将组播流转化为单播流。
5、 如权利要求 4所述的方法， 其特征在于， 向所述用户设备播放所述单播 流的步骤包括：
媒体服务器通过实施流协议 RTSP协议建立与用户设备的流媒体连接通 道；
媒体服务器通过所述流媒体连接通道播放所述单播流。
6、 如权利要求 5所述的方法， 其特征在于， 所述媒体服务器通过所述流媒 体连接通道播放所述单播流之后还包括：
媒体服务器接收所述用户设备发送时移控制请求；媒体服务器根据所述控 制请求， 对所述播放的单播流进行时移控制。
7、 如权利要求 6所述的方法， 其特征在于， 所述单播流播放结束或者用户 主动退出， 则用户设备向所述业务控制功能设备发送会话请求， 所述请求中包 含频道标识， 业务控制功能设备识别该频道为单播频道， 则发送会话结束请求 给媒体服务器；
媒体服务器收到所述业务控制功能设备的会话结束请求，则释放与所述用 户设备的流媒体连接通道， 结束会话。
8、 一种会话请求发送方法， 其特征在于， 包括：
获取网络侧下发的频道元数据； 所述频道元数据中包含频道类型信息； 根据所述元数据获取单元获取的频道元数据中的频道类型信息生成加入 频道的会话建立请求， 所述会话建立请求包含所述频道标识； 若所述频道类型 为组播频道， 则生成的会话建立请求包含组播频道的 SDP信息， 若所述频道类 型为单播频道， 则生成的会话建立请求包含单播频道的 SDP信息。
9、 如权利要求 8所述的方法， 其特征在于， 所述消息生成单元生成的会话 建立请求中包含频道标识或所述频道类型信息，以便于网络侧根据所述频道标 识或所述频道类型信息识别所述频道的类型。
10、 一种频道元数据发送方法， 其特征在于， 包括：
接收用户设备发起的频道元数据获取请求；
根据所述接收单元接收的用户的获取请求获取所述元数据存储单元存储 的频道元数据； 所述频道元数据包括频道的类型标识；
将所述获取的包括频道类型标识的频道元数据下发给用户设备。
11、 如权利要求 10所述的方法， 其特征在于， 所述元数据存储单元存储的 频道元数据还包括频道的組播地址，若所述频道类型为组播频道， 则所述组播 地址用于用户设备接收组播流； 若所述频道类型为单播频道， 则所述组播地址 用于媒体服务器获取组播流， 并将组播流转为单播流。
12、 一种网络电视频道业务处理方法， 其特征在于， 包括：
接收用户设备发送的请求加入频道的会话建立请求；
识别频道的类型； 若所述用户设备请求加入的频道的类型为单播频道， 则 通知媒体服务器根据所述频道的对应的组播流地址，将組播流转换为单播流后 向所述用户设备播放。
13、 一种用户设备， 其特征在于， 包括：
元数据获取单元， 用于获取网络侧下发的频道元数据； 所述频道元数据中 包含频道类型信息；
消息生成单元，用于根据所述元数据获取单元获取的频道元数据中的频道 类型信息生成加入频道的会话建立请求， 所述会话建立请求包含所述频道标 识； 若所述频道类型为組播频道， 则生成的会话建立请求包含组播频道的 SDP 信息， 若所述频道类型为单播频道， 则生成的会话建立请求包含单播频道的 SDP信息。
14、 如权利要求 13所述的用户设备， 其特征在于， 所述消息生成单元生成 的会话建立请求中包含频道标识或所述频道类型信息，以便于网络侧根据所述 频道标识或所述频道类型信息识别所述频道的类型。
15、 如权利要求 13或 14所述的用户设备， 其特征在于， 还包括： 播放单元，用于与网络侧建立媒体连接通道， 并通过建立的媒体连接通道 接收单播媒体流。
16、 如权利要求 15所述的用户设备， 其特征在于， 还包括：
控制单元，用于向媒体服务器发送时移控制请求，对所述媒体连接通道接 收的单播媒体流进行时移控制。
17、 一种元数据服务器， 其特征在于， 包括：
接收单元， 用于接收用户设备发起的频道元数据获取请求；
元数据存储单元， 用于存储频道元数据， 所述存储的频道元数据包括频道 的类型标识；
元数据获取单元，用于根据所述接收单元接收的用户的获取请求获取所述 元数据存储单元存储的频道元数据； 下发单元，用于将所述元数据获取单元获取的包括频道类型标识的频道元数据 下发给用户设备。
18、 如权利要求 17所述的元数据服务器， 其特征在于， 所述元数据存储单 元存储的频道元数据还包括频道的組播地址， 若所述频道类型为组播频道， 则 所述組播地址用于用户设备接收組播流； 若所述频道类型为单播频道， 则所述 组播地址用于媒体服务器获取组播流， 并将组播流转为单播流。
19、 一种业务控制功能设备， 其特征在于， 包括：
接收单元， 用于接收用户设备发送的请求加入频道的会话建立请求； 频道识别单元， 用于识别频道的类型；
通知单元，用于在所述频道识别单元识别所述用户设备请求加入的频道的 类型为单播频道时， 通知媒体服务器根据所述频道的对应的组播流地址，将組 播流转换为单播流。
20、 如权利要求 19所述的业务控制功能设备， 其特征在于， 所述频道识别 单元包括：
元数据请求单元， 用于向元数据服务器请求元数据；
类型识别单元， 用于获取所述元数据服务器返回的频道元数据， 并根据所 述频道元数据内的类型标识确定所述频道的频道类型。
21、 一种媒体服务器， 其特征在于， 包括：
媒体控制单元，用于接收业务控制功能设备的请求，与用户建立控制连接； 媒体传输单元， 用于再媒体控制单元的控制下， 根据组播流的地址， 将组 播流转化为单播流， 并向用户播放所述单播流。
22、 如权利要求 21所述的媒体服务器， 其特征在于， 所述媒体控制单元， 还用于接收用户的控制请求，根据用户的控制请求对媒体传输单元传输的单播 流进行控制。
PCT/CN2009/072543 2009-06-30 2009-06-30 网络电视频道业务实现方法和相关设备 WO2011000151A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2009/072543 WO2011000151A1 (zh) 2009-06-30 2009-06-30 网络电视频道业务实现方法和相关设备
CN2009801476169A CN102150407B (zh) 2009-06-30 2009-06-30 网络电视频道业务实现方法和相关设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2009/072543 WO2011000151A1 (zh) 2009-06-30 2009-06-30 网络电视频道业务实现方法和相关设备

Publications (1)

Publication Number Publication Date
WO2011000151A1 true WO2011000151A1 (zh) 2011-01-06

Family

ID=43410452

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/072543 WO2011000151A1 (zh) 2009-06-30 2009-06-30 网络电视频道业务实现方法和相关设备

Country Status (2)

Country Link
CN (1) CN102150407B (zh)
WO (1) WO2011000151A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111314378A (zh) * 2020-03-18 2020-06-19 浩云科技股份有限公司 一种码流数据处理方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1964345A (zh) * 2006-09-25 2007-05-16 杭州华为三康技术有限公司 组播流的处理方法及网络设备
WO2008057034A1 (en) * 2006-11-07 2008-05-15 Telefonaktiebolaget Lm Ericsson (Publ) Media channel management
CN101346929A (zh) * 2005-12-22 2009-01-14 卢森特技术有限公司 用于在单播会话与组播会话之间进行转换的方法
CN101431653A (zh) * 2008-12-03 2009-05-13 中兴通讯股份有限公司 一种创建和点播频道的方法、系统及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101346929A (zh) * 2005-12-22 2009-01-14 卢森特技术有限公司 用于在单播会话与组播会话之间进行转换的方法
CN1964345A (zh) * 2006-09-25 2007-05-16 杭州华为三康技术有限公司 组播流的处理方法及网络设备
WO2008057034A1 (en) * 2006-11-07 2008-05-15 Telefonaktiebolaget Lm Ericsson (Publ) Media channel management
CN101431653A (zh) * 2008-12-03 2009-05-13 中兴通讯股份有限公司 一种创建和点播频道的方法、系统及装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111314378A (zh) * 2020-03-18 2020-06-19 浩云科技股份有限公司 一种码流数据处理方法
CN111314378B (zh) * 2020-03-18 2022-07-29 浩云科技股份有限公司 一种码流数据处理方法

Also Published As

Publication number Publication date
CN102150407B (zh) 2013-12-04
CN102150407A (zh) 2011-08-10

Similar Documents

Publication Publication Date Title
US8046479B2 (en) Media channel management
CN100579209C (zh) 基于ngn网络实现时移电视业务的方法及系统、媒体资源设备
EP2241078B1 (en) Method and internet protocol television (iptv) content manager server for iptv servicing
US8307049B2 (en) Method and device for obtaining media description information of IPTV services
EP2175591B1 (en) A method, a system, a device and a computer program readable medium for realizing the services of network televison
US8326942B2 (en) IP unicast streaming service delivery
US20090183211A1 (en) System, method and device for enabling ims terminals to access existing iptv services
WO2009117919A1 (zh) 一种内容点播业务的建立方法、系统和装置
US20110067081A1 (en) Switching Between Delivery Methods In An IPTV Communication Network
WO2008037218A1 (fr) Procédé, système et serveur multimédia permettant une commutation rapide d&#39;un canal de télévision sur internet (iptv)
WO2007093127A1 (fr) Système, procédé et dispositif de configuration d&#39;une session média interactive d&#39;après un sous-système ip multimédia
WO2009024092A1 (fr) Procédé et système permettant la commande d&#39;autorisation de ressource de service
WO2009138006A1 (zh) 媒体播放控制的方法及系统、元数据执行单元
WO2008134955A1 (fr) Procédé, système et appareil pour appliquer des informations de capacité de terminal dans un service iptv
WO2009143743A1 (zh) 一种媒体播放方法、系统以及播放代理装置
WO2008110122A1 (fr) Procédé, système et entité tampon de commutation de chaînes de téléréseau
WO2009030133A1 (fr) Procédé, système et entité pour réaliser une vidéo image dans image
WO2011015015A1 (zh) 内容上行方法及内容交付功能实体
WO2008148326A1 (fr) Procédé, système, agent d&#39;activité et terminal pour réaliser une activité de convergence
WO2010028601A1 (zh) 以文件方式传输媒体内容的方法、系统及设备
WO2009132564A1 (zh) 播放控制的方法、装置及系统
WO2009049518A1 (fr) Procédé, système et entité d&#39;établissement de session de système de télévision par internet ip
Shibeshi et al. Using an RTSP Proxy to implement the IPTV Media Function via a streaming server
WO2011000151A1 (zh) 网络电视频道业务实现方法和相关设备
WO2011017897A1 (zh) 一种媒体推荐方法与媒体控制方法及用户网关

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980147616.9

Country of ref document: CN

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

Ref document number: 09846680

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09846680

Country of ref document: EP

Kind code of ref document: A1