WO2009043254A1

WO2009043254A1 - A method, an apparatus and a system for obtaining media processing information

Info

Publication number: WO2009043254A1
Application number: PCT/CN2008/072226
Authority: WO
Inventors: Xiao Wang
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2007-09-14
Filing date: 2008-09-01
Publication date: 2009-04-09
Also published as: CN101388783B; CN101388783A

Abstract

The invention discloses a method, an apparatus and a system for obtaining media processing information, so as to make the applying server obtain the media processing information. The method includes: the applying server interacts with the media resources server; the applying server obtains the media processing information from the messages interacting with the media resources server. The applying server includes a receiving unit and an obtaining unit. The media resources server includes an adding unit and a transmitting unit. The invention is applied to the applying server to obtain media information.

Description

Method, device and system for acquiring media processing information

The present invention relates to the field of communications, and in particular, to a method, device and system for acquiring media processing information.

Background technique

IPTV (Internet Protocol Television) is a brand-new technology that uses broadband cable TV networks to integrate Internet, multimedia, and communication technologies to provide home users with a variety of interactive services, including digital TV. The user can enjoy the IPTV service using the PC or the network set-top box + the ordinary TV mode at home, and can also enjoy the IPTV service through the mobile terminal. IPTV uses TCP/IP as the bearer protocol for unicast, broadcast or multicast video services, effectively combining the three fields of TV network, telephone network and Internet. It is the most representative service of triple play and is being received by the industry. More and more attention.

IMS based IPTV provides IPTV services under the overall architecture of IMS to fully utilize the existing registration, authentication, routing, session control and establishment, service triggering, charging, and end-to-end QoS guarantee mechanisms in the IMS network. Provide streaming services and multimedia services that integrate streaming media and real-time session services. That is to say, the multimedia session of the user to the content is completed by the existing session control mechanism of the IMS. During the establishment of the session, the bearer resource needs to be reserved for the transmission of the media stream.

Currently, many standards organizations are researching IMS based IPTV. See Figure 1 for the service functional architecture of IMS based IPTV defined by the standard organization ETSI TISPAN.

Among them, the IPTV Media Control Functions ( IPTV Media Control Functions) is responsible for the control and delivery of the UE media stream (Delivery). Decomposed from the functional perspective to the MCF Media Control Function and the MDF Media Delivery Function. The media delivery function entity is usually a media server that transmits the media stream required by the user to the user terminal under the control of the media control function entity. The media control function entity can also receive and process the user's playback control operations (usually using the RTSP protocol), such as media fast forward, backward, pause, locate, etc. Operation.

The IPTV Service Control Functions are responsible for providing services to the UE, including: session initialization, user account control, and control of the MCF to provide corresponding media functions. The SCF service control function (Intermediate Control Function) interacts with the MCF through the y2 interface to request media processing services.

The inventor found in the process of the invention that there is currently no need to implement an application server (the application server is SCF in the TISPAN IPTV, and the application server is the application server AS in the IMS architecture) to obtain media processing information. Summary of the invention

Embodiments of the present invention provide a method, device, and system for acquiring media processing information, so that an application server can obtain media processing information.

A method for obtaining media processing information according to an embodiment of the present invention includes the following steps: The application server interacts with a media resource server; and the application server obtains media processing information from a message exchanged with the media resource server.

An application server according to an embodiment of the present invention includes: a receiving unit, configured to receive a message sent by a media resource server; and a learning unit, configured to obtain media processing information from a message received by the receiving unit.

A media resource server according to an embodiment of the present invention includes: an adding unit, configured to carry media processing information in a message to be sent, and a sending unit, configured to send the message to an application server.

A system for obtaining media processing information includes: an application server and a media resource server having a message interaction relationship; a media resource server, configured to send a message carrying media processing information; and an application server, for using the media The media processing information is obtained from the message sent by the resource server.

In the method, device and system of the embodiment of the present invention, the application server interacts with the media resource server, and obtains media processing information from a message exchanged with the media resource server. Through the above mechanism, the application server can obtain media processing information.

DRAWINGS Figure 1 is a diagram showing the service function architecture of IMS based IPTV defined by the existing standards organization ETSI TISPAN;

2 is a flow chart of a method for obtaining media processing information according to an embodiment of the present invention; FIG. 3 is a schematic structural diagram of an application server according to an embodiment of the present invention;

4 is a schematic structural diagram of a media resource server according to an embodiment of the present invention;

FIG. 5 is a schematic diagram of a system for acquiring media processing information according to an embodiment of the present invention; FIG.

6 is a flowchart of an event subscription mode in a SIP mode according to an embodiment of the present invention;

FIG. 7 is a flowchart of an event publishing mode in a SIP mode according to an embodiment of the present invention;

8 is a flowchart of an active uplink mode in a SIP mode according to an embodiment of the present invention;

FIG. 9 is a flowchart of a query mode in a media control mode according to an embodiment of the present invention;

FIG. 10 is a flowchart of a subscription mode in a media control mode according to an embodiment of the present invention;

11 is a flowchart of an active reporting mode in a media control mode according to an embodiment of the present invention; FIG. 12 is a flowchart of Embodiment 1 of the present invention;

13 is a flowchart of Embodiment 2 of the present invention;

Figure 14 is a flowchart of Embodiment 3 of the present invention;

Figure 15 is a flowchart of Embodiment 4 of the present invention;

16 is a flowchart of Embodiment 5 of the present invention;

Figure 17 is a flow chart of Embodiment 6 of the present invention.

detailed description

In order to enable the application server to obtain the media processing information, the embodiment of the present invention provides a method for obtaining media processing information. Referring to FIG. 2, the following main steps are included:

51. The application server interacts with the media resource server.

52. The application server obtains media processing information from a message that interacts with the media resource server. The media processing information includes status information of the media processing and/or indication information that a related event has occurred.

An embodiment of the present invention further provides an application server, as shown in FIG. 3, which includes: a receiving unit 100 and a learning unit 200. The receiving unit 100 is configured to receive a message sent by the media resource server.

The learning unit 200 is configured to obtain media processing information from a message received by the receiving unit.

Another embodiment of the application server: the receiving unit 100 includes a first receiving subunit, configured to receive, by using a SIP mode, a SIP message sent by a media resource server;

The application server further includes: a first subscription unit, configured to send a subscription message to the media resource server, where the indication carries the media processing information of the subscription specified media stream.

Another embodiment of the application server: the receiving unit 100 includes a second receiving subunit, configured to receive, by using a media control manner, a media control message sent by the media resource server;

The application server further includes: a query unit, configured to send, to the media resource server, a query message for querying media processing information of the specified media stream.

The application server further includes: a second subscription unit, configured to send a subscription message to the media resource server, where the SDP serial number of the specified media stream and the indication of subscribing to the specific media processing information are carried.

The embodiment of the present invention further provides a media resource server, as shown in FIG. 4, which includes: an adding unit 300 and a sending unit 400.

The adding unit 300 is configured to carry media processing information in the message to be sent;

The sending unit 400 is configured to send the message to the application server.

Another embodiment of the media resource server: the sending unit 400 includes a first sending sub-unit, configured to send the message in a SIP format to an application server by using a SIP method;

The media resource server further includes: a first receiving unit, configured to receive a subscription message sent by the application server; a first subscription execution unit, configured to complete the subscription according to the indication in the subscription message, and add the unit according to the subscription relationship indication Media processing information that should be carried in the message to be sent.

The media resource server further includes: an event publishing unit, configured to determine media processing to be released Information, and instructing the adding unit to carry the media processing information in the message to be sent.

The media resource server further includes: a first reporting unit, configured to determine the media processing information to be reported according to the processing logic, and instruct the adding unit to carry the media processing information in the SIP INFO message to be sent.

When the media resource server receives the media flow control instruction of the user, the first reporting unit determines the current media processing information to be reported according to the processing logic, and instructs the adding unit to carry the related media processing in the SIP INFO message to be sent. Information

When the media stream ends normally or an error occurs in the media stream playing, the first reporting unit determines the current media processing information to be reported according to the processing logic, and instructs the adding unit to carry the related media processing in the SIP INFO message to be sent. information.

Another embodiment of the media resource server: the sending unit 400 includes a second sending subunit, configured to send the message of the media control type to the application server by using a media control manner; The receiving unit is configured to receive the query message sent by the application server, and the query execution unit is configured to query the media processing information according to the indication in the query message, and instruct the adding unit to carry the media processing information in the message to be sent.

Another embodiment of the media resource server: the sending unit 400 includes a second sending subunit, configured to send the message of the media control type to the application server by using a media control manner; a receiving unit, configured to receive a subscription message sent by the application server, a second subscription execution unit, configured to complete the subscription according to the indication in the subscription message, and instruct the adding unit to carry in the message to be sent according to the subscription relationship The media processes the information.

Another embodiment of the media resource server: the sending unit 400 includes a second sending subunit, configured to send the message of the media control type to the application server by using a media control manner; The second reporting unit is configured to determine the media processing information to be reported according to the processing logic, and instruct the adding unit to carry the media processing information in the message to be sent. When the media resource server receives the media flow control instruction of the user, the second reporting unit determines the current media processing information to be reported according to the processing logic, and instructs the adding unit to carry the message related to the user in the message to be sent. Media processing information;

When the media stream ends normally or an error occurs in the media stream playing, the second reporting unit determines the current media processing information to be reported according to the processing logic, and instructs the adding unit to carry the related media processing information in the message to be sent.

The embodiment of the present invention further provides a system for acquiring media processing information, as shown in FIG. 5, including: an application server 500 and a media resource server 600 having a message interaction relationship;

The media resource server 500 is configured to send a message carrying media processing information.

The application server 600 is configured to obtain media processing information from a message sent by the media resource server. In the TISPAN IPTV, the application server in the embodiment of the present invention is a service control function entity SCF, and the media resource server is a media function entity MF. The media function entity MF includes a media control function entity MCF and a media delivery function entity MDF. During the business development process, the service control function entity SCF interacts with the media control function entity MCF to implement the service, and the media control function entity MCF controls the media delivery function entity MDF to complete media processing and delivery.

In the IMS architecture, the application server in the embodiment of the present invention is an application server AS, and the media resource server is a media resource function entity MRF. The media resource function entity MRF includes a media resource function control entity MRFC and a media resource function processing entity MRFP. During the service development process, the application server AS interacts with the media resource function control entity MRFC to implement the service, and the media resource function control entity MRFC controls the media resource function processing entity MRFP to complete media processing and delivery.

The following describes the embodiment in the case of the TISPAN IPTV. The related process is also applicable to the interaction between the AS and the MRFC in the IMS architecture, and will not be repeatedly described in the embodiment.

For convenience of description, the MCF described in the embodiment of the present invention is a media resource server. When MCF and MDF are used as a whole, the description MCF represents MF.

In the embodiment of the present invention, the SCF can learn the media processing information through the SIP mode or the media control mode. In the SIP mode, the SCF can learn the media processing information through the event subscription mode (mode 11) or the event publishing mode (mode 12) or the active reporting mode (mode 13). The following describes the event subscription mode in the SIP mode. Mode 11), event publishing mode (mode 12) and active reporting mode (mode 13).

Method 11, event subscription mode, as shown in Figure 6, includes the following steps:

As a subscriber, Fl and SCF send a subscription message to the MCF, and subscribe to a status event package related to the specified media stream.

F2, MCF returns 200 OK to SCF.

According to the event subscription mechanism, F3 and MCF send a NOTIFY message to the SCF to return the subscribed status event package.

After receiving the status event package, F4 and SCF return 200 OK to the MCF. The status information of the media processing is obtained from the status event package.

Among them, a key problem to be solved is that in the above process, the MCF can determine the subscribed media stream according to the information carried in the subscription message. The information carried in the subscription message in the current event subscription mechanism cannot specify the media stream. The embodiment of the present invention provides the following three implementation manners:

Method 111: The SCF sends a subscription message within the Dialog that establishes the media session to subscribe to the status event package of the media stream. If the subscription message does not carry the information about the media stream to be subscribed, the scenario may be applied to the scenario in which the media session established by the SCF and the MCF has only one media stream; if the subscription message carries the information about the media stream to be subscribed to. , see the following method 113 for details.

Method 112: The SCF sends a subscription message to the MCF (not sent in the Dialog of the media session), and the subscription message carries the Dialog identifier (including Call-ID, From-tag, and To-tag) that establishes the subscribed media stream and is subscribed. The m line number of the media stream in the SDP (if no m line number is used, all media streams described in the SDP are subscribed by default). Specifically, it can be applied to a scenario where there are multiple (at least two) media streams in a media session established by the SCF and the MCF, and a scenario in which only one media stream is in the media session established by the SCF and the MCF.

In the mode 112, the manner in which the Dialog identifier and the m-line sequence number are carried in the subscription message Including but not limited to the following three types:

The mode 112A is carried in the message body of the subscription message, as shown in the following example:

In this example, an XML description is defined to carry the Dialog identifier and the m-line number, where call-id, from-tag, to-tag represents the Dialog identifier, mid represents the m-line number, and mid can be multiple. Of course, the description in the actual application is various, so the embodiment of the present invention is not limited to this example, and it is a spirit of the present invention to carry a Dialog identifier and a m-line number to identify a media stream.

<?xml version="1.0" encoding="UTF-8"?>

<Flowparam xmlns="urn:ietf:params:xml:ns:Flowparam "

Xmlns:xsi ^=M http:〃 www.w3.org/2001/XMLSchema-instance">

<mid>

1

</mid>

</dialog>

< Flowparam >

Mode 112B, extending a new header field to carry.

Define a new SIP header field to carry the Dialog identifier and m line number. The syntax can be defined as follows: mflow "Mflow" HCOLON callid *(SEMI mflow-param) SEMI mid

Mflow-param to-tag I from-tag I generic-param

To-tag "to-tag" EQUAL token

From-tag "from-tag" EQUAL token

Mid "mid" EQUAL midvalue *("-" midvalue)

Midvalue 1*DIGIT For example, Mflow: 425928@example.com; to-tag=7743; from-tag=6472;mid=l

Specify a media stream with m line number (mid ) of 1 in SDP

Mflow: 425928 (3⁄4example.com; to-tag=7743; from-tag=6472; mid=l-3

Specify two media streams in the SDP with m line numbers ( mid ) 1 and 3.

Method 112C. The extended Request-URI parameter is carried.

By extending the parameters defining the Request-URI to carry the Dialog identifier and the m-line sequence number, the other-param part of the uri-parameter of the Request-URI can be extended. The original uri-parameter is defined as follows: Uri-parameters = *( ";" uri-parameter)

Uri-parameter = transport-param I user-param I method-param

I ttl-param I maddr-param I lr-param I other-param is defined as follows:

Uri-parameters = *( ";" uri-parameter)

Uri-parameter = transport-param I user-param I method-param

I ttl-param I maddr-param I lr-param I call-id I from-tag I to-tag I mid /other-param

Call-id = "call-id=" CALLID

From-tag = "from-tag=" token

To-tag = "to-tag=" token

Mid = "mid=" midvalue *("-" midvalue)

Midvalue =1 * DIGIT

m ^ port , SUBSCRIBE sip: mcf.example.com; call-id=425928@example.com;to-tag=7743; from-tag=6472; mid=l

Subscribe to a media stream with a m line number (mid ) of 1 in the specified SDP

SUBSCRIBE sip: mcf.example.com; call-id=425928@example.com;to-tag=7743; from-tag=6472; mid=l-2

Subscribe to two media streams in the specified SDP with m line numbers (mid ) 1 and 2

Method 113: The SCF sends a subscription message in the Dialog that establishes the media session, and carries the m-line sequence number of the subscribed media stream in the SDP in the subscription message (if no m-line sequence number, all the media streams described in the SDP are subscribed by default) . Specifically, it can be applied to a scenario where there are multiple (at least two) media streams in a media session established by the SCF and the MCF, and a scenario in which only one media stream is in the media session established by the SCF and the MCF. The manner in which the m-line sequence number is carried in the subscription message includes, but is not limited to, the following three types: carried in the message body of the subscription message, extended by a new header field, or extended by the Request-URI parameter.

Method 12, event publishing mode, as shown in Figure 7, includes the following steps:

Fl and MCF release relevant state event packets to the SCF through the event publishing mechanism. In addition to the media playback status, the status event package should also include the corresponding Dialog identifier and the serial number of the media stream in the SDP.

After receiving the status event packet, the SCF returns a 200 OK to the MCF. The status information of the media processing is obtained from the status event package.

Mode 13, MCF active mode, MCF can also actively use the SIP INFO message Body flow related status information. Referring to Figure 8, the following steps are included:

Fl: The MCF triggers the status information of the media processing and/or the indication of the related event to be reported to the SCF according to the media processing logic. (The processing logic may be the processing logic that is solidified by the MCF itself, or may be the processing logic included in the control script delivered by the SCF).

Specifically, the MCF triggers the status information of the media processing to the SCF and/or the indication information of the related event including the following:

In the first case, when the MCF receives the media flow control instruction of the user, the MCF triggers the indication information of the current media processing information to be reported to the SCF.

In the second case, when the media stream ends normally or an error occurs in the media stream, the MCF triggers the indication information of the current media processing information to be reported to the SCF.

Specifically, the media processing information is media processing status information.

The F2 and the MCF send the status information of the media processing and/or the indication information of the related event through the SIP INFO message to the SCF.

In the foregoing case 1, the MCF reports a SIP INFO message to the SCF, where the SIP INFO message carries current media processing status information related to the user. For example, the MCF detects the end of the media stream playback, or when the user issues the instruction to switch the media stream, the MCF reports the SIP INFO message carrying the relevant current media processing status information to the SCF;

In the foregoing case 2, the media resource server reports a SIP INFO message to the SCF, where the SIP INFO message carries relevant current media processing status information. For example, when an error occurs in the playback of the media stream, the MCF reports the SIP INFO message carrying the relevant current media processing status information to the SCF.

F3, SCF returns 200 OK after receiving the SIP INFO message.

Of course, other SIP messages are the same as INFO, such as MESSAGE, and technically can also convey media stream related status information, which will not be described here.

So far, the SCF is informed of the status information of the media processing by the SIP method. The following description makes the SCF know the status information of the media processing through the media control mode. In the media control mode, the media control channel is first established between the SCF and the MCF, and then the SCF can obtain the status information of the media processing through the SCF active acquisition mode (mode 21) or the MCF active reporting mode (mode 22). The SCF active acquisition mode (mode 21) and the MCF active reporting mode (mode 22) in the media control mode.

Method 21, SCF active acquisition mode.

In the SCF active acquisition mode, the method may further include: an SCF query mode (method 211) or an SCF subscription mode (mode 212), which are described in detail below.

211. Query mode: The SCF sends a query message to the MCF to query the status information of the specified media processing. The MCF returns the status of the query media stream to the SCF. For details, refer to FIG. 9, which includes the following steps:

F1-F3: The SCF and the MCF interact to establish a media control channel through the SIP SDP;

F4: The SCF sends a query message (MRequest) to the MCF through the media control channel, carrying the SDP sequence number of the specified media stream and an indication for querying a certain state;

F5: The MCF acknowledges receipt of the inquiry message and returns a response;

F6: The MCF sends a notification message (MNotify) to the SCF to carry status information of the media stream.

The mode is as follows: The SCF sends a subscription message to the MCF to subscribe to the specified media stream state, and the MCF returns the status of the subscribed media stream to the SCF. When the status of the subscribed media stream changes, the MCF sends the status of the changed media stream to the SCF. , and unsubscribe. See Figure 10 for details, including the following steps:

F4: The SCF sends a subscription message (MRequest) to the MCF through the media control channel, carrying the SDP sequence number of the specified media stream and an indication of subscribing to a certain state;

F5: The MCF acknowledges receipt of the inquiry message and returns a response;

F6: The MCF sends a notification message (MNotify) to the SCF to carry status information of the media stream;

F7: When the media stream status changes, the MCF sends status information to the SCF;

F8: SCF sends unsubscribe message (MRequest), cancels the media stream subscribed on MCF State information

F9: The MCF returns a response (MResponse), receiving a request from the SCF.

Mode 22, MCF active reporting mode.

The MCF actively sends the media processing information to the SCF according to the processing logic when performing the media processing. The information may be the status information of the media processing or the indication information of the related event. See Figure 11 for details, including the following steps:

F1-F3: The SCF and MCF interact to establish a media control channel through the SIP SDP.

F4: The MCF triggers the status information of the media processing and/or the indication information of the related event to be reported to the SCF according to the media processing logic. The processing logic may be the processing logic of the MCF itself, or may be included in the control script delivered by the SCF. Processing logic).

In the first case, when the MCF receives the media flow control instruction of the user, the MCF triggers the indication information of the current media processing status information to be reported to the SCF.

In the second case, when the media stream ends normally or an error occurs in the media stream, the MCF triggers the indication information of the related media processing status information to be reported to the SCF.

F5: The MCF sends a notification message (MNotify) to the SCF to carry the status information of the media processing and/or the indication information of the related event.

In the foregoing case 1, the MCF sends a notification message to the SCF, where the notification message carries current media processing status information related to the user. For example, the MCF detects that the playback of the media stream ends, or when the user issues an instruction to switch the media stream, the MCF reports the notification message carrying the relevant current media processing status information to the SCF;

In the foregoing case 2, the media resource server sends a notification message to the SCF, where the notification message carries relevant current media processing status information. For example, when the media stream ends normally, the MCF reports a notification message carrying the relevant media processing status information to the SCF.

The media processing logic can be implemented by defining a common XML description of the event framework. Now, each service in the IPTV can be extended according to the framework to define specific event types and event data, and implement event-triggered reporting. Specific examples are as follows:

<?xml version="1.0" encoding="UTF-8"?>

<iptvevent xmlns="urn:ietf:params:xml:ns:iptvevent"

Xmlns:xsi ^=M http:〃 www.w3.org/2001/XMLSchema-instance">

<event type= ""> /* Event type */

Data... /* The data portion of the event, different events have different data,

Need to be defined according to the specific event type */

</event>

</iptvevent> So far, the SCF has learned the description of the status information of the media processing through the SIP mode or the media control mode. The following is further described in detail through the six embodiments.

Embodiment 1 The SIP PUBLISH mode (event release mode) is used to enable the SCF to know the location information of the media stream.

When the user watches the time shift program (TsTV) or the COD on demand program, when the user changes other channels or the user quits the program being watched, the SCF needs to know the location information of the media stream of the user watching the program, so that the user can watch the program again when from the top. The exit position continues to play.

Define the media stream playback location event package:

Package name: mediapos

Message content indication ( content-type ): application/mediapos+xml

The format of the event package defined in XML description is as follows:

<?xml version="1.0" encoding="UTF-8"?>

<mediapos xmlns="urn:ietf:params:xml:ns:mediapos"

Xmlns:xsi ^=M http:〃 www.w3.org/2001/XMLSchema-instance">

<position type="current-time"> /* Absolute time */

2005-08-15T10:22:00.000-05:00

</position>

</mediapos>

<?xml version="1.0" encoding="UTF-8"?>

<mediapos xmlns="urn:ietf:params:xml:ns:mediapos"

Xmlns:xsi ^=M http:〃 www.w3.org/2001/XMLSchema-instance">

<position type="offset-time"> /* time offset */

0T10: 22:00 /* days T hours: minutes: seconds */

</position>

</mediapos>

<?xml version="1.0" encoding="UTF-8"?>

<mediapos xmlns="urn:ietf:params:xml:ns:mediapos"

Xmlns:xsi ^=M http:〃 www.w3.org/2001/XMLSchema-instance">

<position type="offset-file"> /* file offset */

28629 /* can be defined as Byte (byte) according to the actual situation.

kByte (kilobytes), number of file blocks, etc. */

</position>

</mediapos> Based on the above definition, as shown in FIG. 12, the flow of this embodiment includes the following steps:

F1: The user terminal sends a BYE message to the SCF to exit the current COD or TsTV program;

F2: The SCF sends a BYE message to the MCF to end the media session between the UE and the MCF;

F3: MCF returns 200 OK confirmation to SCF;

F4: The SCF returns a 200 OK confirmation to the UE;

F5: F2 step, after receiving the BYE message of the SCF, the MCF sends the BYE message to the SCF through the PUBLISH message to match the current play position information of the media stream associated with the media session;

F6: The SCF receives the PUBLISH message sent by the MCF, and the play location information is saved from the user-related service data.

In the second embodiment, the SCF uses the event query mode of the media control message to learn the location information of the media stream. The definitions of the application scenario and the event package in this implementation include, but are not limited to, the definitions of the application scenario and the event package described in the first embodiment. Referring to FIG. 13, the flow of this embodiment includes the following steps: Fl: the user terminal sends a BYE message to the SCF to exit the current COD or TsTV program;

F2: The SCF sends a media query message (MRequest) to the MCF through the media control channel, and the query BYE message matches the current play location information of the media stream associated with the media session;

F3: The MCF receives the MRequest message and returns a MResponse response message.

F4: The MCF sends the MNotify message to the SCF to carry the play position information of the media stream;

F5: The SCF sends a BYE message to the MCF to end the media session between the UE and the MCF;

F6: MCF returns 200 OK confirmation to SCF;

F7: The SCF returns a 200 OK confirmation to the UE.

Embodiment 3: The SCF uses the SIP SUBSCRIBE mode (event subscription mode) to learn the RTSP playback status information of the media stream.

In the TsTV and COD services, the RTSP control channel established between the UE and the MCF controls the media stream to advance, rewind, pause, and locate. The SCF needs to know the RTSP status (forward, backward, pause, locate, play) of the media stream at any time. Business development.

Define the RTSP play status event package:

Package name: rtspstatus

Message content indication ( content-type ): application/ rtspstatus+xml

事件Event package format defined by XML description

<?xml version="1.0" encoding="UTF-8"?>

<rtspstatus xmlns="urn:ietf:params:xml:ns:rtspstatus"

Xmlns:xsi ^=M http:〃 www.w3.org/2001/XMLSchema-instance">

Pause /* play (back), back (fast forward), forward (fast forward),

Pause (pause), goto (position) */

</status>

</rtspstatus> Based on the above definition, referring to FIG. 14, the flow of this embodiment includes the following steps:

Fl: The SCF sends a SUBSCRIBE request to the MCF to carry the identifier of the Dialog that establishes the subscribed media stream and the sequence number of the m-line of the subscribed media stream in the SDP, and subscribes to the RTSP status information of the media stream; F2: MCF accepts SCF subscription, returns 200 OK confirmation;

F3: The MCF sends a NOTIFY message to the SCF, carrying the RTSP status information of the subscribed media stream; F4: The SCF receives the NOTIFY message, and returns a 200 OK confirmation;

F5: The UE terminal controls the media stream to fast forward through the RTSP, and the RTSP status of the media stream changes. The MCF sends a NOTIFY message to the SCF to carry the latest RTSP status information of the media stream.

F6: SCF receives the NOTIFY message and returns 200 OK to confirm.

In the fourth embodiment, the SCF uses the media control channel subscription mode to learn the RTSP playback status information of the media stream. The definition of the application scenario and the event package in this implementation is the same as that in the third embodiment. Referring to Figure 15, the flow of this embodiment includes the following steps:

Prerequisite: The UE establishes a media session and media control channel with the MCF.

Fl: The SCF sends a media control message MRequest for subscribing to the RTSP status information to the MCF through the media control channel, and the message carries the sequence number of the m line of the subscribed media stream in the SDP;

F2: The MCF accepts the SCF subscription and returns the MResponse response message.

F3: The MCF sends an MNotify message to the SCF through the media control channel, and carries the RTSP status information of the subscribed media stream.

F4: The UE terminal controls the media stream to fast forward through the RTSP, and the RTSP status of the media stream changes. The MCF sends an MNotify message to the SCF to carry the latest RTSP status information of the media stream.

Embodiment 5: The active control mode of the media control channel is used to enable the SCF to know the TsTV service fast forward to the header indication information.

In the TsTV service, the UE controls the media stream to fast forward through the RTSP. When fast forwarding to synchronize with the currently live media stream, the SCF needs to obtain this information in order to switch the TsTV service to the LTV service.

According to the event description framework defined in the embodiment of the present invention, a specific TsTV service fast forward to event is defined:

Event Type: tstvtop

Data section: None

A specific example is as follows: <?xml version="1.0"encoding="UTF-8"?>

<iptvevent xmlns="urn:ietf:params:xml:ns:iptvevent"

Xmlns:xsi ^=M http:〃 www.w3.org/2001/XMLSchema-instance">

</event>

</iptvevent> Based on the above definition, as shown in FIG. 16, the flow of this embodiment includes the following steps:

Prerequisite: The UE establishes a media session and media control channel with the MCF, and the UE controls the media stream to continuously fast forward through the RTSP.

Fl: The MCF detects that the TsTV service media stream is synchronized with the current LTV media stream (playing content), and the MCF generates an IPTV event, and the event type is "tstvtop", which is sent to the SCF through the MNotify message, to notify the SCF TsTV service media stream that the synchronization has reached the synchronization state.

In the sixth embodiment, the active control mode of the media control channel is used to enable the SCF to learn the recording space exhaustion event. In the network recording service, the SCF that provides the recording service needs to first apply to the MF for the recorded storage space. In some cases, the SCF cannot predict the required recording space, so the recording space can only be recorded by applying while recording. When it is exhausted, the MF notifies the SCF through the event, and the SCF decides to continue the application or end the recording according to the situation.

Define a specific recording space exhaustion event according to the event description framework defined in the invention: Event Type: vr-no-space

Data section:

<?xml version="1.0" encoding="UTF-8"?>

<xs: schema targetNamespace=" urn:ietf:params:xml:ns:pvrdata"

Xmlns:xs= ^M http://www.w3.org/2001/XMLSchema ^M

elementFormDefault="qualified"

attributeFormDefault="unqualified">

<space type=""> /* type includes time, size, and can also be recorded

Remaining space or time */

Specific time or space

</space>

</ xs: schema > A specific example is as follows: <?xml version="1.0"encoding="UTF-8"?>

<iptvevent xmlns="urn:ietf:params:xml:ns:iptvevent"

Xmlns: pd=" urn: ietf : ar ams: xml: ns: vrdata "

Xmlns:xsi ^=M http:〃 www.w3.org/2001/XMLSchema-instance">

<pd: space type="size">

128k /* The remaining space that can be recorded is 128 kilobytes */

</pd:space>

</event>

</iptvevent>

<?xml version="1.0" encoding="UTF-8"?>

<iptvevent xmlns="urn:ietf:params:xml:ns:iptvevent"

Xmlns: pd=" urn: ietf: par ams: xml: ns: p vrdata "

Xmlns:xsi ^=M http:〃 www.w3.org/2001/XMLSchema-instance">

<pd: space type="time">

20s /* The remaining time that can be recorded is 20 seconds */

</pd:space>

</event>

</iptvevent> Based on the above definition, as shown in FIG. 17, the flow of this embodiment includes the following steps:

F1-F3: The SCF interacts with the MCF to apply for recording space and establish a media control channel;

F4: During the recording process, the MCF finds that the remaining space or time of recording is less than the set value, triggers the reporting event, and sends an MNotify message carrying the event indication "vr-no-space" to the SCF and the remaining space or time size;

F5-F7: The SCF receives the MNotify message and decides to continue recording according to the service condition. The SCF requests the recording space by sending an INVITE message or an UPDATE message in the session to the MCF.

(If F5 is an UPDATE message, there is no ACK for F7).

In summary, in the method, device and system of the embodiment of the present invention, the application server interacts with the media resource server, and obtains media processing information from the message interacting with the media resource server. Through the above mechanism, the application server can obtain media processing information.

Specifically, the present invention further provides a solution for the media resource server to report media processing information to the application server, and an application server, in the process of processing the streaming media by the media resource server. According to the progress of the business, several solutions for obtaining media processing information from the media resource server are needed, thereby better supporting the present invention. The spirit and scope of the Ming. Thus, it is intended that the present invention cover the modifications and the modifications of the invention

Claims

Claim

A method for obtaining media processing information, comprising the steps of: an application server interacting with a media resource server;

The application server obtains media processing information from messages that interact with the media resource server.

The method for obtaining media processing information according to claim 1, wherein the application server interacts with the media resource server by means of SIP, and the application server sends a subscription message to the media resource server, where the subscription carries the specified media stream. The media processes the indication of the information, and obtains media processing information of the media stream from the message returned by the media resource server.

3. The method for obtaining media processing information according to claim 2, wherein the subscription is initiated by the media resource server to determine media processing information of the subscribed media stream:

The application server sends a subscription message in the media session to subscribe to the media processing information of the media stream in the media session; or

The subscription message sent by the application server to the media resource server carries the Dialog identifier of the media stream and the line number of the media stream in the SDP to subscribe to the media processing information of the media stream.

The method for obtaining media processing information according to claim 3, wherein, in the manner of sending a subscription message in the media session, the subscription message carries the media stream in the media session in the SDP. Line number.

The method for obtaining media processing information according to claim 1, wherein the application server interacts with the media resource server by means of SIP, and the application server obtains media processing information from the message issued by the media resource server through the event publishing mechanism. .

The method for obtaining the media processing information according to claim 1, wherein the application server interacts with the media resource server through the SIP mode, and the application server actively reports the SIP INFO according to the processing logic when performing the media processing from the media resource server. Get media processing information in the message.

The method for obtaining media processing information according to claim 6, wherein the media resource server actively reports the SIP INFO message according to the processing logic when the media resource server performs the media processing, including:

When the media resource server receives the media flow control instruction of the user, the media resource server The SIP INFO message is actively reported to the application server, where the SIP INFO message carries relevant current media processing information;

When the media stream ends normally or an error occurs in the media stream, the media resource server actively reports a SIP INFO message to the application server, where the SIP INFO message carries relevant media processing information.

The method for obtaining media processing information according to claim 1, wherein the application server and the media resource server interact through the media control mode, and the application server sends a query to the media resource server for querying the media processing information of the specified media stream. The message, and the media processing information of the media stream is obtained from the message returned by the media resource server.

The method for obtaining media processing information according to claim 1, wherein the application server and the media resource server interact through the media control mode, and the application server sends a subscription message to the media resource server, where the specified media stream is carried. The SDP sequence number and an indication of subscribing to the specific media processing information, and obtaining media processing information of the media stream from the message returned by the media resource server.

The method for obtaining the media processing information according to claim 1, wherein the application server interacts with the media resource server through the media control mode, and the application server actively reports the message according to the processing logic when the media resource server performs the media processing. Get media processing information.

The method for obtaining media processing information according to any one of claims 1 to 10, wherein the media processing information is status information of media processing.

The method for obtaining media processing information according to claim 6, 7 or 9, wherein the media processing information is indication information that a related event has occurred.

13. An application server, comprising:

a receiving unit, configured to receive a message sent by a media resource server;

The learning unit is configured to obtain media processing information from the message received by the receiving unit.

The application server according to claim 13, wherein the receiving unit includes: a first receiving subunit, configured to receive, by using a SIP mode, a SIP message sent by a media resource server; or

a second receiving subunit, configured to receive media sent by the media resource server by using a media control manner Control messages.

The application server according to claim 14, wherein the receiving unit includes a first receiving subunit, and the application server further includes: a first subscribing unit, configured to send a subscription message to the media resource server. , carrying an indication of media processing information subscribed to the specified media stream.

The application server according to claim 14, wherein the receiving unit includes a second receiving subunit, and the application server further includes: a query unit, configured to send a query to the media resource server to specify the media stream. The media handles the query information for the information.

The application server according to claim 14, wherein the receiving unit includes a second receiving subunit, and the application server further includes: a second subscribing unit, configured to send a subscription message to the media resource server. And carrying an SDP sequence number of the specified media stream and an indication of subscribing to the specific media processing information.

18. A media resource server, comprising:

An adding unit, configured to carry media processing information in the message to be sent;

a sending unit, configured to send the message to an application server.

The media resource server according to claim 18, wherein the sending unit includes:

a first sending subunit, configured to send the message in a SIP format to an application server by using a SIP method; or

And a second sending subunit, configured to send the message of the media control type to the application server by using a media control manner.

The media resource server according to claim 19, wherein the sending unit includes a first sending subunit, and the media resource server further includes:

a first receiving unit, configured to receive a subscription message sent by an application server;

And a first subscription execution unit, configured to complete the subscription according to the indication in the subscription message, and instruct, according to the subscription relationship, the media processing information that the adding unit should carry in the message to be sent.

The media resource server according to claim 19, wherein: in the sending unit Including the first sending subunit, the media resource server further includes:

The event issuing unit is configured to determine media processing information to be advertised, and instruct the adding unit to carry the media processing information in the message to be sent.

The first reporting unit is configured to determine the media processing information to be reported according to the processing logic, and instruct the adding unit to carry the media processing information in the SIP INFO message to be sent.

The media resource server according to claim 19, wherein the sending unit includes a second sending subunit, and the media resource server further includes:

a second receiving unit, configured to receive a query message sent by the application server;

The query execution unit is configured to query the media processing information according to the indication in the query message, and instruct the adding unit to carry the media processing information in the message to be sent.

a third receiving unit, configured to receive a subscription message sent by the application server;

And a second subscription execution unit, configured to complete the subscription according to the indication in the subscription message, and instruct, according to the subscription relationship, the media processing information that the adding unit should carry in the message to be sent.

The second reporting unit is configured to determine the media processing information to be reported according to the processing logic, and instruct the adding unit to carry the media processing information in the message to be sent.

26. A system for obtaining media processing information, comprising: an application server and a media resource server having a message interaction relationship;

a media resource server, configured to send a message carrying media processing information; and an application server, configured to obtain media processing information from a message sent by the media resource server.