CN101388783A - 一种获取媒体处理信息的方法、装置及系统 - Google Patents

一种获取媒体处理信息的方法、装置及系统 Download PDF

Info

Publication number
CN101388783A
CN101388783A CN 200710145492 CN200710145492A CN101388783A CN 101388783 A CN101388783 A CN 101388783A CN 200710145492 CN200710145492 CN 200710145492 CN 200710145492 A CN200710145492 A CN 200710145492A CN 101388783 A CN101388783 A CN 101388783A
Authority
CN
China
Prior art keywords
media
process information
message
resource server
application server
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
CN 200710145492
Other languages
English (en)
Other versions
CN101388783B (zh
Inventor
王啸
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Weiben Intellectual Property Management Co. Ltd.
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN 200710145492 priority Critical patent/CN101388783B/zh
Priority to PCT/CN2008/072226 priority patent/WO2009043254A1/zh
Publication of CN101388783A publication Critical patent/CN101388783A/zh
Application granted granted Critical
Publication of CN101388783B publication Critical patent/CN101388783B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • 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/10—Architectures or entities
    • H04L65/1063—Application servers providing network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/222—Secondary servers, e.g. proxy server, cable television Head-end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6156—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network
    • H04N21/6175—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8543—Content authoring using a description language, e.g. Multimedia and Hypermedia information coding Expert Group [MHEG], eXtensible Markup Language [XML]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本发明公开了一种获取媒体处理信息的方法、装置及系统，以使应用服务器可获取媒体处理信息。方法包括下列步骤：应用服务器与媒体资源服务器交互；应用服务器从与媒体资源服务器交互的消息中获取媒体处理信息。应用服务器包括：接收单元，用于接收媒体资源服务器发来的消息；获知单元，用于从接收单元收到的消息中获取媒体处理信息。媒体资源服务器包括：添加单元，用于在待发送的消息中携带媒体处理信息；发送单元，用于向应用服务器发送该消息。

Description

一种获取媒体处理信息的方法、装置及系统
技术领域
本发明涉及通信领域，特别是涉及一种获取媒体处理信息的方法、装置及系统。
背景技术
IPTV(Internet Protocol Television互联网协议电视)是一种利用宽带有线电视网，集互联网、多媒体、通讯等多种技术于一体，向家庭用户提供包括数字电视在内的多种交互式服务的崭新技术。用户在家中可以使用PC或者网络机顶盒+普通电视机方式享受IPTV业务，也可以通过移动终端享受IPTV业务。IPTV使用TCP/IP作为承载协议进行单播、广播或组播视频业务，有效地将电视网、电话网和互联网三个领域结合在一起，是三网融合最具代表性的业务，正受到业界越来越多的关注。
IMS based IPTV就是在IMS的整体架构下提供IPTV业务，以充分利用IMS网络中已有的注册、认证、路由、会话控制与建立、业务触发、计费、端到端QoS保证等机制来为用户提供流媒体业务及融合流媒体和实时会话业务的多媒体业务。也就是说，用户到内容的多媒体会话是通过IMS已有的会话控制机制来完成，在建立会话过程中，需要为媒体流的传送预留承载资源。
目前，许多标准组织在研究IMS based IPTV。参见图1所示为标准组织ETSI TISPAN定义的IMS based IPTV的业务功能架构。
其中，IPTV媒体控制功能实体(IPTV Media Control Functions)负责到UE媒体流的控制与交付(Delivery)。从功能角度分解为MCF媒体控制功能实体(Media Control Function)和MDF媒体交付功能实体(Media DeliveryFunction)。媒体交付功能实体通常是一些媒体服务器，在媒体控制功能实体的控制下向用户终端传送用户需要的媒体流。媒体控制功能实体还能接收和处理用户的播放控制操作(通常使用RTSP协议实现)，例如媒体的快进、后退、暂停、定位等操作。
IPTV业务控制功能实体(IPTV Service Control Functions)负责向UE提供业务，包括：会话初始化，用户帐户控制，控制MCF提供相应的媒体功能等。其中SCF业务控制功能实体(Service Control Function)通过y2接口与MCF交互，请求媒体处理服务。
发明人在发明过程中发现，目前没有实现应用服务器(在TISPAN IPTV中应用服务器为SCF，在IMS架构中应用服务器为应用服务器AS)获取媒体处理信息这一需求。
发明内容
本发明实施例提供一种获取媒体处理信息的方法、装置及系统，以使应用服务器可获取媒体处理信息。
本发明实施例的一种获取媒体处理信息的方法，包括下列步骤：应用服务器与媒体资源服务器交互；应用服务器从与媒体资源服务器交互的消息中获取媒体处理信息。
本发明实施例的一种应用服务器，包括：接收单元，用于接收媒体资源服务器发来的消息；获知单元，用于从接收单元收到的消息中获取媒体处理信息。
本发明实施例的一种媒体资源服务器，包括：添加单元，用于在待发送的消息中携带媒体处理信息；发送单元，用于向应用服务器发送该消息。
本发明实施例的一种获取媒体处理信息的系统，包括：存在消息交互关系的应用服务器和媒体资源服务器；媒体资源服务器，用于发送携带有媒体处理信息的消息；应用服务器，用于从媒体资源服务器发来的消息中获取媒体处理信息。
本发明实施例的方法、装置及系统中，应用服务器与媒体资源服务器交互，并从与媒体资源服务器交互的消息中获取媒体处理信息。通过上述机制实现了使应用服务器可获取媒体处理信息。
附图说明
图1为现有标准组织ETSI TISPAN定义的IMS based IPTV的业务功能架构图；
图2为本发明实施例的一种获取媒体处理信息的方法步骤流程图；
图3为本发明实施例的一种应用服务器的结构示意图；
图4为本发明实施例的一种媒体资源服务器的结构示意图；
图5为本发明实施例的SIP方式下的事件订阅模式的流程图；
图6为本发明实施例的SIP方式下的事件发布模式的流程图；
图7为本发明实施例的SIP方式下的主动上报模式的流程图；
图8为本发明实施例的媒体控制方式下的查询方式的流程图；
图9为本发明实施例的媒体控制方式下的订阅方式的流程图；
图10为本发明实施例的媒体控制方式下的主动上报模式的流程图；
图11为本发明实施例一的流程图；
图12为本发明实施例二的流程图；
图13为本发明实施例三的流程图；
图14为本发明实施例四的流程图；
图15为本发明实施例五的流程图；
图16为本发明实施例六的流程图。
具体实施方式
为了使应用服务器可获取媒体处理信息，本发明实施例提供了一种获取媒体处理信息的方法，参见图2所示，包括下列主要步骤：
S1、应用服务器与媒体资源服务器交互。
S2、应用服务器从与媒体资源服务器交互的消息中获取媒体处理信息。所述媒体处理信息包括媒体处理的状态信息和/或发生了相关事件的指示信息。
本发明实施例提供还了一种应用服务器，参见图3所示，其包括：接收单元和获知单元。
接收单元，用于接收媒体资源服务器发来的消息。
获知单元，用于从接收单元收到的消息中获取媒体处理信息。
应用服务器的另一个实施例：所述接收单元中包括第一接收子单元，用于通过SIP方式接收媒体资源服务器发来的SIP消息；则
所述应用服务器还包括：第一订阅单元，用于向媒体资源服务器发送订阅消息，其中携带有订阅指定媒体流的媒体处理信息的指示。
应用服务器的另一个实施例：所述接收单元中包括第二接收子单元，用于通过媒体控制方式接收媒体资源服务器发来的媒体控制消息；则
所述应用服务器还包括：查询单元，用于向媒体资源服务器发出查询指定媒体流的媒体处理信息的查询消息。
应用服务器的另一个实施例：所述接收单元中包括第二接收子单元，用于通过媒体控制方式接收媒体资源服务器发来的媒体控制消息；则
所述应用服务器还包括：第二订阅单元，用于向媒体资源服务器发送订阅消息，其中携带有指定媒体流的SDP序号和订阅特定媒体处理信息的指示。
本发明实施例还提供了一种媒体资源服务器，参见图4所示，其包括：添加单元和发送单元。
添加单元，用于在待发送的消息中携带媒体处理信息；
发送单元，用于向应用服务器发送该消息。
媒体资源服务器的另一个实施例：所述发送单元中包括第一发送子单元，用于通过SIP方式向应用服务器发送SIP格式的所述消息；则
所述媒体资源服务器还包括：第一接收单元，用于接收应用服务器发来的订阅消息；第一订阅执行单元，用于根据所述订阅消息中的指示完成订阅，并根据订阅关系指示添加单元在待发送的消息中应携带的媒体处理信息。
媒体资源服务器的另一个实施例：所述发送单元中包括第一发送子单元，用于通过SIP方式向应用服务器发送SIP格式的所述消息；则
所述媒体资源服务器还包括：事件发布单元，用于确定待发布的媒体处理信息，并指示添加单元在待发送的消息中携带该媒体处理信息。
媒体资源服务器的另一个实施例：所述发送单元中包括第一发送子单元，用于通过SIP方式向应用服务器发送SIP格式的所述消息；则
所述媒体资源服务器还包括：第一上报单元，用于根据处理逻辑确定待上报的媒体处理信息，并指示添加单元在待发送的SIP INFO消息中携带该媒体处理信息。
媒体资源服务器的另一个实施例：所述发送单元中包括第二发送子单元，用于通过媒体控制方式向应用服务器发送媒体控制类型的所述消息；则
所述媒体资源服务器还包括：第二接收单元，用于接收应用服务器发来的查询消息；查询执行单元，用于根据所述查询消息中的指示查询媒体处理信息，并指示添加单元在待发送的消息中携带该媒体处理信息。
媒体资源服务器的另一个实施例：所述发送单元中包括第二发送子单元，用于通过媒体控制方式向应用服务器发送媒体控制类型的所述消息；则
所述媒体资源服务器还包括：第三接收单元，用于接收应用服务器发来的订阅消息；第二订阅执行单元，用于根据所述订阅消息中的指示完成订阅，并根据订阅关系指示添加单元在待发送的消息中应携带的媒体处理信息。
媒体资源服务器的另一个实施例：所述发送单元中包括第二发送子单元，用于通过媒体控制方式向应用服务器发送媒体控制类型的所述消息；则
所述媒体资源服务器还包括：第二上报单元，用于根据处理逻辑确定待上报的媒体处理信息，并指示添加单元在待发送的消息中携带该媒体处理信息。
本发明实施例还提供了一种获取媒体处理信息的系统，包括：存在消息交互关系的应用服务器和媒体资源服务器；
媒体资源服务器，用于发送携带有媒体处理信息的消息。
应用服务器，用于从媒体资源服务器发来的消息中获取媒体处理信息。
在TISPAN IPTV中，本发明实施例中的应用服务器为业务控制功能实体SCF，媒体资源服务器为媒体功能实体MF。而媒体功能实体MF包括媒体控制功能实体MCF和媒体交付功能实体MDF。业务开展过程中，业务控制功能实体SCF与媒体控制功能实体MCF进行交互实现业务，媒体控制功能实体MCF控制媒体交付功能实体MDF完成媒体处理和交付。
在IMS架构中，本发明实施例中的应用服务器为应用服务器AS，媒体资源服务器为媒体资源功能实体MRF。而媒体资源功能实体MRF包括媒体资源功能控制实体MRFC和媒体资源功能处理实体MRFP。业务开展过程中，应用服务器AS与媒体资源功能控制实体MRFC进行交互实现业务，媒体资源功能控制实体MRFC控制媒体资源功能处理实体MRFP完成媒体处理和交付。
以下以TISPAN IPTV为业务场景描述实施例，其相关流程同样可应用于IMS架构下AS与MRFC的交互，在实施例中就不再重复描述。
为了描述方便，本发明实施例中所述的MCF即为媒体资源服务器，当MCF和MDF作为一个整体时，描述MCF即代表MF。
本发明实施例中，可通过SIP方式或媒体控制方式使SCF获知媒体处理信息。
其中SIP方式中，又可通过事件订阅模式(方式11)或事件发布模式(方式12)或主动上报模式(方式13)使SCF获知媒体处理信息，以下分别详述SIP方式下的事件订阅模式(方式11)、事件发布模式(方式12)和主动上报模式(方式13)。
方式11、事件订阅模式，参见图5所示，包括下列步骤：
F1、SCF作为订阅者向MCF发送订阅消息，订阅指定媒体流相关的状态事件包。
F2、MCF向SCF返回200OK。
F3、MCF根据事件订阅机制，向SCF发送NOTIFY消息返回订阅的状态事件包。
F4、SCF收到该状态事件包后，向MCF返回200OK。并从该状态事件包中获知媒体处理的状态信息。
其中，要解决的一个关键问题是上述流程中，MCF能根据订阅消息携带的信息确定被订阅的媒体流。而目前事件订阅机制中的订阅消息携带的信息无法指定媒体流，本发明实施例提供如下三种实现方式：
方式111：SCF在建立媒体会话的Dialog内发送订阅消息，以订阅媒体流的状态事件包。若该订阅消息中不携带欲订阅的媒体流的相关信息，则可应用于SCF与MCF建立的媒体会话中只有一个媒体流的场景；若该订阅消息中携带有欲订阅的媒体流的相关信息，则详见下述方式113。
方式112：SCF向MCF发送订阅消息(不在媒体会话的Dialog内发送)，在该订阅消息中携带建立被订阅媒体流的Dialog标识(包括Ca1l-ID，From-tag和To-tag)和被订阅媒体流在SDP中的m行序号(如果不带m行序号，则默认订阅SDP中描述的所有媒体流)。具体可应用于SCF与MCF建立的媒体会话中有多个(至少两个)媒体流的场景，以及SCF与MCF建立的媒体会话中只有一个媒体流的场景。
在方式112中，在订阅消息中携带所述Dialog标识和所述m行序号的方式包括但不限于以下3种：
方式112A、在订阅消息的消息体携带，具体参见下述示例：
Figure A200710145492D00121
该示例中，定义了一种XML描述方式携带Dialog标识和m行序号，其中call-id，from-tag，to-tag代表Dialog标识，mid代表m行序号，且mid可以是多个。当然，实际应用中描述方式多种多样，所以本发明实施例不限于这一示例，只要携带了Dialog标识和m行序号来标识一个媒体流都属于本发明的精神。
方式112B、扩展一个新的头域携带。
定义一个新的SIP头域来携带Dialog标识和m行序号，语法定义可以如下：
    mflow          ＝＂Mflow＂HCOLON callid*(SEMI mflow-param)
SEMI mid
      mflow-param  ＝to-tag/from-tag/generic-param
      to-tag       ＝＂to-tag＂EQUAL token
      from-tag     ＝＂from-tag＂EQUAL token
      mid          ＝＂mid＂EQUAL midvalue*(＂-＂midvalue)
      midvalue    ＝   1*DIGIT
例如，Mflow：425928@example.com；to-tag＝7743；from-tag＝6472；mid＝1
指定SDP中m行序号(mid)为1的一个媒体流
Mflow：425928＠example.com；to-tag＝7743；from-tag＝6472；mid＝1-3
指定SDP中m行序号(mid)为1和3的两个媒体流
方式112C、扩展Request-URI参数携带。
通过扩展定义Request-URI的参数来携带Dialog标识和m行序号，可以扩展Request-URI的uri-parameter中的other-param部分，原uri-parameter定义如下：
uri-parameters   ＝ *(＂；＂uri-parameter)
uri-parameter    ＝ transport-param/user-param/method-param
                       /ttl-param/maddr-param/lr-param/other-param
扩展后定义如下：
uri-parameters   ＝ *(＂；＂uri-parameter)
uri-parameter    ＝ transport-param/user-param/method-param
                     /ttl-param/maddr-param/lr-param/call-id/
                     from-tag/to-tag/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
例如，SUBSCRIBE sip:mcf.example.com；call-id＝425928＠example.com；to-tag＝7743；from-tag＝6472；mid＝1
订阅指定SDP中m行序号(mid)为1的一个媒体流
SUBSCRIBE sip:mcf.example.com；call-id＝425928＠example.com；to-tag＝7743；from-tag＝6472；mid＝1-2
订阅指定SDP中m行序号(mid)为1和2的两个媒体流
方式113：SCF在建立媒体会话的Dialog内发送订阅消息，在订阅消息中携带被订阅媒体流在SDP中的m行序号(如果不带m行序号，则默认订阅SDP中描述的所有媒体流)。具体可应用于SCF与MCF建立的媒体会话中有多个(至少两个)媒体流的场景，以及SCF与MCF建立的媒体会话中只有一个媒体流的场景。在订阅消息中携带m行序号的方式包括但不限于以下3种：在订阅消息的消息体携带，扩展一个新的头域携带，或者扩展Request-URI参数携带。
方式12、事件发布模式，参见图6所示，包括下列步骤：
F1、MCF通过事件发布机制，向SCF发布相关的状态事件包。状态事件包中除了媒体播放状态外，还应包括对应的Dialog标识和媒体流在SDP中的序列号。
F2、SCF收到该状态事件包后，向MCF返回200OK。并从该状态事件包中获知媒体处理的状态信息。
方式13、MCF主动上报模式，MCF还可以通过SIP INFO消息主动上报媒体流相关状态信息。参见图7所示包括下列步骤：
F1：MCF根据媒体处理逻辑，触发向SCF上报媒体处理的状态信息和/或发生了相关事件的指示信息。(处理逻辑可以是MCF本身固化的处理逻辑，也可以是SCF下发的控制脚本中包含的处理逻辑)；
F2、MCF通过SIP INFO消息携带媒体处理的状态信息和/或发生了相关事件的指示信息，发送给SCF；
F3、SCF收到该SIP INFO消息后返回200OK。
当然其它SIP消息同INFO一样，如MESSAGE，技术上也是可以传递媒体流相关状态信息，在此就不在赘述。
至此通过SIP方式使SCF获知媒体处理的状态信息的描述完毕，以下描述通过媒体控制方式使SCF获知媒体处理的状态信息。
在媒体控制方式中，首先在SCF与MCF间建立媒体控制通道，之后可通过SCF主动获取模式(方式21)或MCF主动上报模式(方式22)使SCF获知媒体处理的状态信息，以下分别详述媒体控制方式下的SCF主动获取模式(方式21)和MCF主动上报模式(方式22)。
方式21、SCF主动获取模式。
在SCF主动获取模式中，又可包括：SCF查询方式(方式211)或SCF订阅方式(方式212)，以下分别详述。
方式211、查询方式：SCF向MCF发出查询指定媒体处理的状态信息的查询消息，MCF向SCF返回查询媒体流的状态，具体参见图8所示，包括下列步骤：
F1～F3：SCF与MCF通过SIP SDP交互建立媒体控制通道；
F4：SCF通过媒体控制通道向MCF发出查询消息(MRequest)，携带指定媒体流的SDP序号和查询某种状态的指示；
F5：MCF确认收到查询消息，返回响应；
F6：MCF向SCF发送通知消息(MNotify)携带媒体流的状态信息。
方式212、订阅方式：SCF向MCF发出订阅指定媒体流状态的订阅消息，MCF向SCF返回订阅媒体流的状态，当订阅的媒体流状态发生改变时，MCF向SCF发送改变后的媒体流的状态，以及取消订阅。具体参见图9所示，包括下列步骤：
F1～F3：SCF与MCF通过SIP SDP交互建立媒体控制通道；
F4：SCF通过媒体控制通道向MCF发出订阅消息(MRequest)，携带指定媒体流的SDP序号和订阅某种状态的指示；
F5：MCF确认收到查询消息，返回响应；
F6：MCF向SCF发送通知消息(MNotify)携带媒体流的状态信息；
F7：当媒体流状态发生改变时，MCF向SCF发送状态信息；
F8：SCF发送取消订阅消息(MRequest)，取消在MCF上订阅的媒体流状态信息；
F9：MCF返回响应(MResponse)，接收SCF的请求。
方式22、MCF主动上报模式。
MCF执行媒体处理时根据处理逻辑，主动向SCF发送媒体处理的信息，这个信息可以是媒体处理的状态信息，也可以是相关事件的指示信息。具体参见图10所示，包括下列步骤：
F1～F3：SCF与MCF通过SIP SDP交互建立媒体控制通道；
F4：MCF根据媒体处理逻辑，触发向SCF上报媒体处理的状态信息和/或发生了相关事件的指示信息(处理逻辑可以是MCF本身固化的处理逻辑，也可以是SCF下发的控制脚本中包含的处理逻辑)；
F5：MCF向SCF发送通知消息(MNotify)携带媒体处理的状态信息和/或发生了相关事件的指示信息。
所述媒体处理逻辑可通过定义一个通用的XML描述方式的事件框架来实现，IPTV中各个业务可以根据该框架，扩展定义具体的事件类型和事件数据，实现事件触发的上报。具体示例如下：
至此通过SIP方式或媒体控制方式使SCF获知媒体处理的状态信息的描述完毕，以下通过6个实施例进一步详述。
实施例一、采用SIP PUBLISH方式(事件发布模式)使SCF获知媒体流播放位置信息。
用户在观看时移节目(TsTV)或COD点播节目时，当用户更换其它频道或用户退出正在观看的节目，SCF需要获知用户观看节目的媒体流的位置信息，以便用户再次观看该节目时从上次退出位置继续播放。
定义媒体流播放位置事件包：
包名：mediapos
消息内容指示(content-type)：application/mediapos+xml
采用XML描述方式定义的事件包格式如下：
基于上述定义，参见图11所示，本实施例流程包括下列步骤：
F1：用户终端向SCF发送BYE消息退出当前COD或TsTV节目；
F2：SCF向MCF发送BYE消息结束UE与MCF间的媒体会话；
F3：MCF向SCF返回200OK确认；
F4：SCF向UE返回200OK确认；
F5：F2步骤MCF收到SCF的BYE消息后，将BYE消息匹配媒体会话关联的媒体流的当前播放位置信息通过PUBLISH消息发送给SCF；
F6：SCF接收MCF发送的PUBLISH消息，从中取出播放位置信息保存到用户相关的业务数据中。
实施例二、SCF采用媒体控制消息的事件查询方式获知媒体流播放位置信息。本实施对应用场景和事件包的定义包括但不限于实施例一中所述的应用场景和事件包的定义。参见图12所示，本实施例流程包括下列步骤：
F1：用户终端向SCF发送BYE消息退出当前COD或TsTV节目；
F2：SCF通过媒体控制通道向MCF发送媒体查询消息(MRequest)，查询BYE消息匹配媒体会话关联的媒体流的当前播放位置信息；
F3：MCF收到MRequest消息，返回MResponse响应消息；
F4：MCF向SCF发送MNotify消息携带媒体流的播放位置信息；
F5：SCF向MCF发送BYE消息结束UE与MCF间的媒体会话；
F6：MCF向SCF返回200OK确认；
F7：SCF向UE返回200OK确认。
实施例三、SCF采用SIP SUBSCRIBE方式(事件订阅模式)获知媒体流的RTSP播放状态信息。
在TsTV和COD业务中，UE与MCF间建立的RTSP控制通道控制媒体流前进，后退，暂停，定位，SCF需要随时了解媒体流的RTSP状态(前进，后退，暂停，定位，播放)，以便相关业务的开展。
定义RTSP播放状态事件包：
包名：rtspstatus
消息内容指示(content-type)：application/rtspstatus+xml
采用XML描述方式定义的事件包格式
基于上述定义，参见图13所示，本实施例流程包括下列步骤：
F1：SCF向MCF发送SUBSCRIBE请求携带建立被订阅媒体流的Dialog的标识和被订阅媒体流在SDP中的m行的序列号，订阅媒体流的RTSP状态信息；
F2：MCF接受SCF的订阅，返回200OK确认；
F3：MCF向SCF发送NOTIFY消息，携带被订阅媒体流的RTSP状态信息；
F4：SCF收到NOTIFY消息，返回200OK确认；
F5：UE终端通过RTSP控制媒体流快进，导致媒体流的RTSP状态发生变化，MCF向SCF发送NOTIFY消息携带媒体流最新的RTSP状态信息；
F6：SCF收到NOTIFY消息，返回200OK确认。
实施例四、SCF采用媒体控制通道订阅方式获知媒体流的RTSP播放状态信息。本实施对应用场景和事件包的定义与实施例三相同。参见图14所示，本实施例流程包括下列步骤：
前提：UE与MCF建立媒体会话和媒体控制通道。
F1：SCF通过媒体控制通道向MCF发送订阅RTSP状态信息的媒体控制消息MRequest，消息中携带被订阅媒体流在SDP中的m行的序列号；
F2：MCF接受SCF的订阅，返回MResponse响应消息；
F3：MCF通过媒体控制通道向SCF发送MNotify消息，携带被订阅媒体流的RTSP状态信息；
F4：UE终端通过RTSP控制媒体流快进，导致媒体流的RTSP状态发生变化，MCF向SCF发送MNotify消息携带媒体流最新的RTSP状态信息。
实施例五、采用媒体控制通道主动上报模式使SCF获知TsTV业务快进到头指示信息。
在TsTV业务中，UE通过RTSP控制媒体流快进，当快进到与当前直播的媒体流同步时，SCF需要获得这个信息，以便与将TsTV业务切换到LTV业务。
根据本发明实施例中定义的事件描述框架，定义具体的TsTV业务快进到头事件：
事件类型：tstvtop
数据部分：无
一个具体的例子如下：
基于上述定义，参见图15所示，本实施例流程包括下列步骤：
前提：UE与MCF建立媒体会话和媒体控制通道，UE通过RTSP控制媒体流不断的快进。
F1：MCF检测到TsTV业务媒体流与当前LTV媒体流同步(播放内容)，MCF产生一个IPTV事件，事件类型为“tstvtop“通过MNotify消息发送给SCF，通知SCF TsTV业务媒体流已经达到同步状态。
实施例六、采用媒体控制通道主动上报模式使SCF获知录制空间耗尽事件。
在网络录制业务中，提供录制业务的SCF需要先向MF申请录制的存储空间，在某些情况下，SCF不能预知需要的录制空间大小，因此只能通过边申请边录制的方式，当录制空间快耗尽时，MF通过事件通知SCF，SCF根据情况决定再继续申请或结束录制。
根据发明中定义的事件描述框架，定义具体的录制空间耗尽事件：
事件类型：pvr-no-space
数据部分：
Figure A200710145492D00212
一个具体的例子如下：
Figure A200710145492D00221
Figure A200710145492D00222
基于上述定义，参见图16所示，本实施例流程包括下列步骤：
F1～F3：SCF与MCF进行会话交互申请录制空间，并建立媒体控制通道；
F4：MCF在录制过程中发现录制剩余空间或时间小于设定值，触发上报事件，向SCF发送MNotify消息携带事件指示＂pvr-no-space＂和剩余空间或时间大小；
F5～F7：SCF接收MNotify消息，根据业务情况决定继续录制，通过向MCF发送会话内的INVITE消息或UPDATE消息申请录制空间。
(如果F5是UPDATE消息，则没有F7的ACK)。
综上所述，本发明实施例的方法、装置及系统中，应用服务器与媒体资源服务器交互，并从与媒体资源服务器交互的消息中获取媒体处理信息。通过上述机制实现了使应用服务器可获取媒体处理信息。
具体的，本发明还提供了媒体资源服务器执行流媒体的处理过程中，媒体资源服务器需要向应用服务器上报媒体处理信息的若干方案，以及应用服务器根据业务的进展情况需要向媒体资源服务器获取媒体处理信息的若干方案，从而更好的支撑了本发明。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (25)

1、一种获取媒体处理信息的方法，其特征在于，包括下列步骤：
应用服务器与媒体资源服务器交互；
应用服务器从与媒体资源服务器交互的消息中获取媒体处理信息。
2、如权利要求1所述的方法，其特征在于，应用服务器与媒体资源服务器通过SIP方式交互，则应用服务器向媒体资源服务器发送订阅消息，其中携带有订阅指定媒体流的媒体处理信息的指示，并从媒体资源服务器返回的消息中获取该媒体流的媒体处理信息。
3、如权利要求2所述的方法，其特征在于，通过下述方式发起订阅，使媒体资源服务器确定被订阅的媒体流的媒体处理信息：
应用服务器在媒体会话内发送订阅消息，以订阅该媒体会话中媒体流的媒体处理信息；或者，
应用服务器向媒体资源服务器发送的订阅消息中携带有媒体流的Dialog标识和媒体流在SDP中的行序号，以订阅该媒体流的媒体处理信息。
4、如权利要求3所述的方法，其特征在于，所述在媒体会话内发送订阅消息的方式中，所述订阅消息中携带有该媒体会话中媒体流在SDP中的行序号。
5、如权利要求1所述的方法，其特征在于，应用服务器与媒体资源服务器通过SIP方式交互，则应用服务器从媒体资源服务器通过事件发布机制发布的消息中获取媒体处理信息。
6、如权利要求1所述的方法，其特征在于，应用服务器与媒体资源服务器通过SIP方式交互，则应用服务器从媒体资源服务器执行媒体处理时根据处理逻辑主动上报的SIP INFO消息中获取媒体处理信息。
7、如权利要求1所述的方法，其特征在于，应用服务器与媒体资源服务器通过媒体控制方式交互，则应用服务器向媒体资源服务器发出查询指定媒体流的媒体处理信息的查询消息，并从媒体资源服务器返回的消息中获取该媒体流的媒体处理信息。
8、如权利要求1所述的方法，其特征在于，应用服务器与媒体资源服务器通过媒体控制方式交互，则应用服务器向媒体资源服务器发送订阅消息，其中携带有指定媒体流的SDP序号和订阅特定媒体处理信息的指示，并从媒体资源服务器返回的消息中获取该媒体流的媒体处理信息。
9、如权利要求1所述的方法，其特征在于，应用服务器与媒体资源服务器通过媒体控制方式交互，则应用服务器从媒体资源服务器执行媒体处理时根据处理逻辑主动上报的消息中获取媒体处理信息。
10、如权利要求1至9任一项所述的方法，其特征在于，所述媒体处理信息为媒体处理的状态信息。
11、如权利要求6或9所述的方法，其特征在于，所述媒体处理信息为发生了相关事件的指示信息。
12、一种应用服务器，其特征在于，包括：
接收单元，用于接收媒体资源服务器发来的消息；
获知单元，用于从接收单元收到的消息中获取媒体处理信息。
13、如权利要求12所述的应用服务器，其特征在于，所述接收单元中包括：
第一接收子单元，用于通过SIP方式接收媒体资源服务器发来的SIP消息；或者，
第二接收子单元，用于通过媒体控制方式接收媒体资源服务器发来的媒体控制消息。
14、如权利要求13所述的应用服务器，其特征在于，所述接收单元中包括第一接收子单元，则所述应用服务器还包括：第一订阅单元，用于向媒体资源服务器发送订阅消息，其中携带有订阅指定媒体流的媒体处理信息的指示。
15、如权利要求13所述的应用服务器，其特征在于，所述接收单元中包括第二接收子单元，则所述应用服务器还包括：查询单元，用于向媒体资源服务器发出查询指定媒体流的媒体处理信息的查询消息。
16、如权利要求13所述的应用服务器，其特征在于，所述接收单元中包括第二接收子单元，则所述应用服务器还包括：第二订阅单元，用于向媒体资源服务器发送订阅消息，其中携带有指定媒体流的SDP序号和订阅特定媒体处理信息的指示。
17、一种媒体资源服务器，其特征在于，包括：
添加单元，用于在待发送的消息中携带媒体处理信息；
发送单元，用于向应用服务器发送该消息。
18、如权利要求17所述的媒体资源服务器，其特征在于，所述发送单元中包括：
第一发送子单元，用于通过SIP方式向应用服务器发送SIP格式的所述消息；或者，
第二发送子单元，用于通过媒体控制方式向应用服务器发送媒体控制类型的所述消息。
19、如权利要求18所述的媒体资源服务器，其特征在于，所述发送单元中包括第一发送子单元，则所述媒体资源服务器还包括：
第一接收单元，用于接收应用服务器发来的订阅消息；
第一订阅执行单元，用于根据所述订阅消息中的指示完成订阅，并根据订阅关系指示添加单元在待发送的消息中应携带的媒体处理信息。
20、如权利要求18所述的媒体资源服务器，其特征在于，所述发送单元中包括第一发送子单元，则所述媒体资源服务器还包括：
事件发布单元，用于确定待发布的媒体处理信息，并指示添加单元在待发送的消息中携带该媒体处理信息。
21、如权利要求18所述的媒体资源服务器，其特征在于，所述发送单元中包括第一发送子单元，则所述媒体资源服务器还包括：
第一上报单元，用于根据处理逻辑确定待上报的媒体处理信息，并指示添加单元在待发送的SIP INFO消息中携带该媒体处理信息。
22、如权利要求18所述的媒体资源服务器，其特征在于，所述发送单元中包括第二发送子单元，则所述媒体资源服务器还包括：
第二接收单元，用于接收应用服务器发来的查询消息；
查询执行单元，用于根据所述查询消息中的指示查询媒体处理信息，并指示添加单元在待发送的消息中携带该媒体处理信息。
23、如权利要求18所述的媒体资源服务器，其特征在于，所述发送单元中包括第二发送子单元，则所述媒体资源服务器还包括：
第三接收单元，用于接收应用服务器发来的订阅消息；
第二订阅执行单元，用于根据所述订阅消息中的指示完成订阅，并根据订阅关系指示添加单元在待发送的消息中应携带的媒体处理信息。
24、如权利要求18所述的媒体资源服务器，其特征在于，所述发送单元中包括第二发送子单元，则所述媒体资源服务器还包括：
第二上报单元，用于根据处理逻辑确定待上报的媒体处理信息，并指示添加单元在待发送的消息中携带该媒体处理信息。
25、一种获取媒体处理信息的系统，其特征在于，包括：存在消息交互关系的应用服务器和媒体资源服务器；
媒体资源服务器，用于发送携带有媒体处理信息的消息；
应用服务器，用于从媒体资源服务器发来的消息中获取媒体处理信息。
CN 200710145492 2007-09-14 2007-09-14 一种获取媒体处理信息的方法、装置及系统 Expired - Fee Related CN101388783B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN 200710145492 CN101388783B (zh) 2007-09-14 2007-09-14 一种获取媒体处理信息的方法、装置及系统
PCT/CN2008/072226 WO2009043254A1 (fr) 2007-09-14 2008-09-01 Procédé, dispositif et système de collecte d'information de traitement multimédia

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN 200710145492 CN101388783B (zh) 2007-09-14 2007-09-14 一种获取媒体处理信息的方法、装置及系统

Publications (2)

Publication Number Publication Date
CN101388783A true CN101388783A (zh) 2009-03-18
CN101388783B CN101388783B (zh) 2012-12-12

Family

ID=40477979

Family Applications (1)

Application Number Title Priority Date Filing Date
CN 200710145492 Expired - Fee Related CN101388783B (zh) 2007-09-14 2007-09-14 一种获取媒体处理信息的方法、装置及系统

Country Status (2)

Country Link
CN (1) CN101388783B (zh)
WO (1) WO2009043254A1 (zh)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030121054A1 (en) * 2001-12-26 2003-06-26 Digeo, Inc. Display for a client terminal for an interactive video casting system
JP4325297B2 (ja) * 2003-06-27 2009-09-02 パナソニック株式会社 機器操作システム
CN100589487C (zh) * 2006-01-11 2010-02-10 华为技术有限公司 Sip通信网络中和媒体服务器交互的方法
CN100499803C (zh) * 2006-02-23 2009-06-10 华为技术有限公司 网络电视消息通知系统、设备及方法

Also Published As

Publication number Publication date
CN101388783B (zh) 2012-12-12
WO2009043254A1 (fr) 2009-04-09

Similar Documents

Publication Publication Date Title
CN101573943B (zh) 媒体频道管理
CN100421469C (zh) 实现实时视频信息共享的系统及方法
CN1846420B (zh) 嵌入的服务质量相关信息的传送
CN102415071B (zh) 会话推送传输
EP1988666B1 (en) A streaming media network system, a realization method and a enable entity of streaming media service
CN102685563B (zh) 互联网协议电视内容共享方法、装置以及终端设备
CN101861729B (zh) 通过使用会话初始化协议发现互联网协议电视服务iptv提供商和iptv服务的方法和设备
EP1769617A1 (en) Rtsp proxy extended to detect streaming session events and report to valued streaming applications the notified ones
KR100891745B1 (ko) 주문형 비디오 서비스 제공을 위한 프로토콜 변환 방법 및 그 장치
CN101313567B (zh) 电子节目单提供方法、电子节目单系统及业务功能单元
CN101299748A (zh) 在iptv业务中应用终端能力信息的方法、系统及装置
JP2012515484A (ja) ネットワークにおける関連付けられたセッションの管理
CN102131109A (zh) 用于监控流媒体播放的方法、系统及装置
CN101547402B (zh) 一种建立iptv多播业务的方法及设备
US9054891B2 (en) Distributing session initiation protocol content to universal plug and play devices in a local network
CN101453402A (zh) 一种对媒体流控制的方法、系统及设备
CN101951381A (zh) 数字电视接收终端及其实现多媒体即时通讯的方法
CN101674470A (zh) 实现客户端录制的方法、系统及录制控制实体
US7310665B2 (en) Method, gateway system and arrangement in a communication network
CN101388783B (zh) 一种获取媒体处理信息的方法、装置及系统
CN101483532B (zh) 一种媒体流复制的方法、系统及设备
US20110016222A1 (en) Network element for enabling a user of an iptv system to obtain media stream from a surveillance system and corresponding method
CN101340428A (zh) 媒体服务器切换过程中提供媒体流的方法及系统
CN101459572B (zh) 一种在ip分组网中实现关联媒体流的方法及装置
CN101662654A (zh) 基于ims的网络电视系统及该系统的实现方法和装置

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
ASS Succession or assignment of patent right

Owner name: BEIJING WEIBEN INTELLECTUAL PROPERTY MANAGEMENT CO

Free format text: FORMER OWNER: HUAWEI TECHNOLOGY CO., LTD.

Effective date: 20141104

C41 Transfer of patent application or patent right or utility model
COR Change of bibliographic data

Free format text: CORRECT: ADDRESS; FROM: 518129 SHENZHEN, GUANGDONG PROVINCE TO: 100080 HAIDIAN, BEIJING

TR01 Transfer of patent right

Effective date of registration: 20141104

Address after: 100080 room 401A, building 27, 1 Xin Lu, Haidian District, Beijing

Patentee after: Beijing Weiben Intellectual Property Management Co. Ltd.

Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen

Patentee before: Huawei Technologies Co., Ltd.

CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20121212

Termination date: 20150914

EXPY Termination of patent right or utility model