CN1751304A - 在多媒体流中用于信号指示流质量匹配和控制机制的方法 - Google Patents
在多媒体流中用于信号指示流质量匹配和控制机制的方法 Download PDFInfo
- Publication number
- CN1751304A CN1751304A CN 200480004196 CN200480004196A CN1751304A CN 1751304 A CN1751304 A CN 1751304A CN 200480004196 CN200480004196 CN 200480004196 CN 200480004196 A CN200480004196 A CN 200480004196A CN 1751304 A CN1751304 A CN 1751304A
- Authority
- CN
- China
- Prior art keywords
- client computer
- server
- ability
- attribute
- matching mechanisms
- 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.)
- Pending
Links
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
一种在多媒体流服务中在客户机和服务器之间就数据传送过程的匹配方面进行信号指示和协商方法。为了确定客户机支持要用于数据传送中的匹配机制或能力，参加者中的一方提供指示它所支持的匹配机制或能力的信息给另一方。在接收到所述信息后，另一方使用定义好的RTSP响应来指示对那个机制或能力的支持。可以由服务器也可以由客户机来发起协商。信号指示和协商的执行包括了在特定3G PSS会话中的AVPF使用、RTP重传有用负荷格式使用和SRTP使用。
Description
技术领域
本发明通常涉及多媒体流，更具体地说，涉及流质量匹配和控制机制的信号指示。
背景技术
在多媒体流服务中，涉及三个参与者：流服务器、流客户机以及在服务器和客户机之间提供连接性的基础网络。服务器向客户机提供传送多媒体流内容的功能。为此，客户机和服务器就能力交换(capability exchange)的方法、内容传送方法协商、内容传送控制等方面，经由网络相互通信。这样的信息交换能够通过明确定义的网络协议来实现。
为了成功地建立和启动多媒体流会话的，服务器和客户机需要支持由服务选为标准协议的最小的一组协议集。这种服务的一个例子可见于3GPP TS26.234.V5.1.0，“Transparent End-to-End Packet Switched Streaming Service(PSS)；Protocols and Codecs(第5版)”，2002年6月，此后称为TS 26.234。进一步地，从数据传送和重放性能方面看，为了服务的成功，还必须在服务中明确定义数据传送控制机制。这样的机制也用于匹配(adapt)数据传送过程，以便引起基础网络特征中性能的变化。
三种可能的基于对匹配机制或能力进行决定性的控制配置的匹配过程如下：
客户机驱动匹配
客户机控制匹配功能或能力并为匹配做必要的决定。所述决定基于从网络、服务器或其它服务定义中的信息源所采集到的信息。
服务器驱动匹配
服务器控制匹配功能或能力并为匹配做必要的决定。所述决定基于从网络、客户机或者其它服务定义中的信息源所采集到的信息。
合作匹配
对匹配功能或能力的控制分布于服务器和客户机之间。服务器和客户机都能根据从网络、服务器或者其它服务定义中的信息源所采集到的信息为匹配采取行动。
在服务上下文内，可能有不止一种在上述匹配过程的每一个的上下文内定义的匹配机制或能力。可能是这样的情况，即这些匹配机制或能力的每一个在服务中都被标准化了，但是保留了由服务器或客户机来实现的可选性。
因此，需要能力识别机制用于识别所支持的匹配机制或能力，以及匹配能力信号指示和协商机制(adaptation capability signaling and negotiationmechanism)用于服务器和客户机在服务上下文内就定义的一组特定的匹配机制或能力的使用达成一致。
在现有技术中，Annex G of 3G PSS(第5版)定义了信号指示机制，它能够用于用信号指示使用和支持参数，但这并不是一个完全的解决方案。
发明内容
本发明提供了一种在多媒体流服务中就数据传送过程的匹配方面在客户机和服务器之间进行的信号指示和协商的方法。能够使用能力交换机制或使用多媒体流控制协议来实现该方法。按照本发明，信号指示和协商的方法能够在特定3G PSS会话中的AVPF(用于基于PTCP反馈的扩展RTP简档)使用中、特定3G PSS会话中的RTP重传有用负荷格式使用以及特定3G PSS会话中的SRTP的使用中实现。
按照本发明，当多媒体流服务具有明确定义的和/或标准化的匹配过程并且每个匹配过程都由明确定义的和/或标准化的机制组成时，则能执行所述方法，其中所述机制是实施匹配功能或实用能力的工具。而且，每个匹配机制或能力有以下属性，即属性在服务上下文内被明确定义和/或标准化，或者在服务器和客户机之间是熟知的。
相应地，本发明提供了一种用于在多媒体流服务中在客户机和服务器之间进行信号指示和协商的方法，其中客户机支持多个用于数据传送服务的匹配机制或能力，每个匹配机制或能力具有属性。所述方法包括：
客户机提供表示定义客户机支持的匹配机制或能力的属性的信息；
服务器根据所提供的信息选择一个或多个属性；和
服务器进一步提供表示所选择的属性的信息，以便允许客户机知道由服务器所选的一个或多个属性所定义的一个或多个匹配机制或能力。
按照本发明，客户机通过能力交换机制或通过多媒体流控制协议来提供信息。
可选地，所述方法包括：
由两个参加者中的一方向两个参加者中的另一方提供指明定义一个或多个匹配机制或能力的一个或多个属性的信息；和
响应所述信息，从所述另一方传递消息给所述一方，确认对所述一个或多个匹配机制或能力的支持。
或者由客户机或者由服务器来发起协商。如果客户机发起协商，则客户机提供多个属性给服务器；并且服务器根据所提供的信息选择一个或多个所提供的属性以确认支持。
附图说明
图1示出了按照本发明的作为信号指示和协商过程的一部分的客户机所作的声明。
图2示出了按照本发明的由服务器向客户机发送的指示所选择的属性的SDP描述。
图3示出了由服务器发送的RTSP消息中的SDP描述。
图4示出了由服务器发送的RTSP DESCRIBE响应。
图5示出了按照本发明的另一个实施例的作为信号指示和协商过程的一部分的客户机所作的声明。
图6示出了按照本发明的另一个实施例的由服务器向客户机发送的指示所选择的属性的SDP描述。
图7示出了由服务器发送的RTSP消息中的SDP描述。
图8示出了由服务器发送的RTSP DESCRIBE响应。
图9示出了按照本发明的又一实施例的作为信号指示和协商处理的一部分的客户机所作的声明。
图10示出了根据本发明的由服务器向客户机发送的指示所选择的属性的SDP描述。
图11示出了由服务器发送的RTSP消息中的SDP描述。
图12示出了由服务器发送的RTSP DESCRIBE响应。
图13是一个流程图，解释在客户机和服务器之间就数据传送过程的匹配方面进行的信号指示和协商的方法，其中由客户机发起协商。
图14是一个流程图，解释信号指示和协商的方法，其中由服务器发起协商。
具体实施方式
根据本发明，在多媒体流服务中在客户机和服务器之间就数据传送过程的匹配方面进行信号指示和协商的方法，能够通过能力交换机制或通过多媒体流控制协议来实现。数据传送过程的匹配是基于一个或多个匹配机制或能力的一个或多个属性，所述属性用于确定在多媒体流服务中的匹配过程。
当通过能力交换机制来实现信号指示和协商时，对步骤的描述如下：
-客户机在它的能力简档(capability profile)中声明由它执行的匹配机制或能力的属性，能力简档是为能力交换机制而定义的；
-服务器获得所述能力简档；
-当服务器知道了哪个匹配机制或能力由客户机执行时，服务器选择与匹配过程不冲突的属性的一个子集。根据所选择的属性的子集，服务器制作多媒体会话描述并向客户机声明会话描述；和
-根据会话描述，客户机知道了用于特定多媒体会话的由服务器执行的匹配机制或能力选择。缺省情况下，客户机接受描述中所声明的匹配机制或能力，因为所声明的描述包含了由客户机所声明的属性或匹配机制能力的子集。
当通过多媒体流控制协议实现信号指示和协商时，对步骤的描述如下：
-客户机包括在为控制流会话而定义的多媒体流控制协议(MultimediaStreaming Control Protocol)中的由客户机执行的匹配机制或能力的属性；
-根据那些属性，服务器知道了客户机执行或请求的匹配机制或能力。服务器选择与匹配过程不冲突的属性的一个子集，并向客户机信号指示所选择的或未选择的属性。取决于现阶段的控制通信，服务器可根据所选择的属性制作多媒体会话描述，并向客户机声明会话描述；和
-根据来自服务器的响应，客户机知道了由服务器所选择的属性。缺省情况下，客户机接受由服务器选择的属性所定义的匹配机制或能力，因为所选择的匹配机制或能力是由客户机声明的匹配机制或能力的一个子集。
按照本发明，能够在基于TS 26.234或更晚版本的多媒体流服务中执行所述信号指示和协商的方法。
所述执行涵盖定义、信号指示和协商的下述机制：
-在特定3G PSS会话(例如参见，IETF draft-ietf-avt-rtcp-feedback-04：“Extended RTP profile for RTCP-based Feedback(RTP/AVPF)”，Ott等人，2002，此后被称作draft-avpf-04)中的AVPF使用；
-在特定3G PSS会话(例如参见，IETF draft-ietf-avt-rpt-retransmission-05：“RTP Retransmission Payload Format”，Rey等人，2002，此后被称作draft-retransmission-05)中的RTP重传有用负荷格式使用；和
-在特定3G PSS会话(例如参见，IETF draft-ietf-avt-srtp-05：“The SecureReal-time Transport Protocol”，Baugher等人，2002，此后被称作draft-srtp-05)中的SPTP使用。
I.在特定3GPSS会话中的AVPF使用
如果draft-avpf-04中所定义的AVPF由客户机支持，并且客户机信号指示AVPF支持，那么服务器可能在匹配过程中使用如定义于draft-avpf-04中的AVPF特征的任意组合。如果存在明确定义的用于那个特征的机制标志符，则客户机也可能分别信号指示AVPF(例如，即时反馈模式、早期RTCP数据包支持等)的每个可支持特征。
假设属性“AVPFSupport”定义于RDF(资源描述框架)模式符号集(Schemavocabulary)中，以信号指示定义于draft-avpf-04中的对音频和视频媒体的AVPF支持。
假设属性“UnSupportedAdaptationSupport”在RDF模式符号集中定义为匹配机制或能力，它由客户机支持，而不被服务器支持。
假设属性“SupportedAdaptationSupport”在RDF模式符号集中定义为匹配机制或能力，它也被服务器支持。
假设属性“x-avpfsupport”是明确定义的SDP(会话描述协议)属性，当AVPF被支持时，该属性包括在SDP的音频和视频(或在两种媒体类型中使用的会话层)媒体部分中。
假设“x-unsupportedadaptationsupport”是明确定义的SDP属性，当被支持时，该属性包括在SDP(会话或媒体层)中。
假设“x-supportedadaptationsupport”是明确定义的SDP属性，当被支持时，该属性包括在SDP(会话或媒体层)中。
A.通过可能的能力交换机制进行信号指示和协商：
-客户机发送带有指向驻留在能力交换服务器中的客户机能力信息的URL的RTSP DESCRIBE请求给服务器。
-服务器从能力交换服务器取客户机的能力声明。声明包括如图1所示的用于客户端流能力的一部分。
在声明中的粗线表示客户机的匹配机制支持能力。应当注意到，当属性值为TRUE时，所述机制或能力被客户机支持。相反地，当属性值为FALSE时，所述机制或能力不被客户机支持。例如，如果属性AVPFSupport为TRUE，则它声明客户机具有对特定会话中的音频和视频媒体元件的AVPF支持。
-知道了这种能力之后，服务器制作要发送至客户机的SDP描述，该描述包括AVPF能力和Supported AdaptationSupport能力。SDP描述显示于图2中。服务器不包括基于Unsupported AdaptationSupport的SDP属性，因为服务器并不支持该属性。在SDP描述中的粗线指示AVPF的使用和对SupportedAdaptationSupport的支持。
-通过接收这个SDP描述，客户机知道AVPF将用于视频元件，而不用于音频元件。AVPF也有可能既用于音频也用于视频元件。在这种情况下，“a＝x-avpfsupport”将是一个会话层SDP属性。客户机知道不使用UnsupportedAdaptationSupprt，并且SupportedAdaptationSupprt机制或能力将用于音频和视频媒体。
B.通过一个可能的多媒体流控制协议进行信号指示和协商：
在3GPSS中，RTSP协议用于控制多媒体会话。
假设“x-avpfsupport”是明确定义的RTSP选择标签，其指示客户机上的AVPF支持。
假设“x-unsupportedadaptationsupport”是明确定义的RTSP选择标签，当被客户机支持时，选择标签被信号指示于RTSP消息中。假定服务器不支持该标签所表示的机制。
假设“x-supportedadaptationsupport”是明确定义的RTSP选择标签，当它被客户机支持时，选择标签被信号指示于RTSP消息中。
假定客户机知道用于多媒体会话的RTSP URL。
-客户机发送具有优选匹配机制或能力的选择的DESCRIBE请求：
客户机->服务器：
DESCRIBE rtsp：//foo/twister RTSP/1.0
CSeq：1
Require：x-avpfsupport，x-unsupportedadaptationsupport，x-supportedadaptationsupport
-客户机使用RTSP Require请求标题(header)来信号指示所支持的机制或能力。
-为了使服务器根据客户机支持的机制或能力成功地制作SDP，在RTSP描述方法之前或在RTSP描述方法中，RTSP请求中所支持的机制或能力由客户机信号指示。
-服务器检查RTSP请求并知道它能使用x-avpfsupport和x-supportedadaptationsupport，但不能使用x-unsupportedadaptationsupport。
服务器有两种可能的方式进行响应：
选择1：
-服务器发送RTSP 551“不支持的选择”响应，包括在消息体中的不支持的机制或能力：
服务器->客户机
RTSP/1.0551不支持的选择
CSeq：1
Unsupported：x-unsupportedadaptationsupport
-客户机发布仅有支持的机制或能力的另一个DESCRIBE请求：
客户机->服务器：
DESCRIBE rtsp：//foo/twister RTSP/1.0
CSeq：2
Require：x-avpfsupport，x-supportedadaptationsupport
-服务器用RTSP 200OK消息来响应，也包含如图3所示的SDP描述。
选择2：
-服务器发送RTSP DESCRIBE响应，包含不支持的机制/能力信息，而没有使用RTSP 551状态响应。RTSP DESCRIBE响应如图4所示。
-服务器使用RTSP Unsupported响应标题来信号指示不可能用于特定会话的不支持的机制或匹配机制或能力，并使用适当的SDP属性来信号指示所选择的匹配机制或能力的使用。
-当客户机接收到采用SDP描述的DESCRIBE响应时，它知道哪些匹配机制或能力的集合被选择用于该特定会话中。
在客户机诸如通过MMS接收来自另一个源的SDP描述的情况下，客户机能够分析SDP描述并找到RTSP会话URL。然后，它能够发送RTSPDESCRIBE请求来信号指示和协商匹配机制或能力。通过事先分析MMS检索到的SDP描述，客户机能够制作匹配机制或能力的集合。这就解决了在服务器端的困惑，因为服务器不能清楚地知道在这种使用情景中的SDP描述的内容。
II.在特定3GPSS会话中的RTP重传有用负荷格式使用
假设在RDF模式符号集中定义属性“RtxSupport”，以信号指示RTP重传机制的使用，该机制定义于用于音频和视频媒体的重传草稿(draft-retransmission)中。由客户端上的AVPF支持自动定义RTX支持。
假设属性“UnSupportedAdaptationSupport”在RDF模式符号集中定义为匹配机制或能力，该机制或能力不被服务器支持，但是被客户机支持。
假设属性“SupportedAdaptationSupport”在RDF模式符号集中定义为也被服务器支持的匹配机制或能力。
假设属性“x-rtxsupport”是明确定义的SDP属性，当支持RTP重传有用负荷格式时，该属性包括在SDP的音频和视频(或在两种媒体类型中使用的会话层)媒体部分中。
假设“x-unsupportedadaptationsupport”是明确定义的SDP属性，当被支持时，该属性包括在SDP(会话或媒体层)中。
假设“x-supportedadaptationsupport”是明确定义的SDP属性，当被支持时，该属性包括在SDP(会话或媒体层)中。
A.通过可能的能力交换机制进行信号指示和协商：
-客户机发送带有指向客户机能力信息的URL的RTSP DESCRIBE请求给服务器，所述信息驻留在能力交换服务器上。
-服务器从能力交换服务器取客户机的能力声明。声明包括如图5所示的用于客户端流能力的一部分。
在声明中的粗线表示客户机的匹配机制支持能力。当RtxSupport为TRUE时，声明客户机具有对特定会话中的音频和视频媒体元件的RTP重传有用负荷格式的支持。
-知道了这种能力之后，服务器制作要发送至客户机的SDP描述，该描述包括RTP重传能力和SupportedAdaptationSupport能力。所述SDP描述显示于图6中。服务器不包括基于UnsupportedAdaptationSupport的SDP属性，因为服务器并不支持该属性。在SDP描述中的粗线指示RTP重传有用负荷格式的使用和对SupportedAdaptationSupport的支持。
-通过接收这个SDP描述，客户机知道RTP重传将用于视频元件，但是不用于音频元件。也明白将不使用UnsupportedAdaptationSupport，并且SupportedAdaptationSupport机制或能力将用于音频和视频媒体。
B.通过可能的多媒体流控制协议进行信号指示和协商：
在3GPSS中，RTSP协议用于控制多媒体会话。
假设“x-rtxsupport”是明确定义的RTSP选择标签，它指示由客户机支持的RTP重传有用负荷格式。
假设“x-unsupportedadaptationsupport”是明确定义的RTSP选择标签，当被客户机支持时，选择标签被信号指示于RTSP消息中。假定服务器不支持这个标签所表示的机制或能力。
假设“x-supportedadaptationsupport”是明确定义的RTSP选择标签，当它被客户机支持时，选择标签被信号指示于RTSP消息中。
假定客户机知道用于多媒体会话的RTSP URL。
-客户机发送具有优选匹配机制或能力的选择的DESCRIBE请求：
客户机->服务器：
DESCRIBE rtsp：//foo/twister RTSP/1.0
CSeq：1
Require：x-rtxsupport，x-unsupportedadaptationsupport，x-supportedadaptationsupport
-客户机使用RTSP Require请求标题来信号指示所支持的匹配机制或能力。
-为了使服务器根据客户机支持的机制或能力成功地制作SDP，在RTSP描述方法之前或在RTSP描述方法中，RTSP请求中所支持的机制或能力由客户机信号指示。
-服务器检查RTSP请求并知道它能使用x-rtpsupport和x-supportedadaptationsupport，但不能使用x-unsupportedadaptationsupport。
服务器具有两种可能的方式来响应：
选择1：
-服务器发送RTSP 551“不支持的选择”响应，包括在消息体中的不支持的机制或能力。
服务器->客户机
RTSP/1.0551不支持的选择
CSeq：1
Unsupported：x-unsupportedadaptationsupport
-客户机发布仅有所支持机制或能力的另一个DESCRIBE请求：
客户机->服务器
DESCRIBE rtsp：//foo/twister RTSP/1.0
CSeq：2
Require：x-rtxsupport，x-supportedadaptationsupport
-服务器用RTSP 200OK消息来响应，也包含如图7所示的SDP描述。
选择2：
-服务器发送RTSP DESCRIBE响应，包含不支持的机制/能力信息，而没有使用RTSP 551状态响应。所述RTSP DESCRIBE响应如图8所示。
-服务器使用RTSP Unsupported响应标题来信号指示不可能用于特定会话的不支持的机制或匹配机制或能力，并使用适当的SDP属性来信号指示所选择的匹配机制或能力的使用。
-当客户机接收到采用SDP描述的DESCRIBE响应时，它知道哪些匹配机制或能力的集合被选择用于该特定会话中。
在客户机诸如通过MMS接收到来自另一个源的SDP描述的情况下，客户机分析SDP描述并找到RTSP会话URL。然后，它发送RTSP DESCRIBE请求来信号指示和协商匹配机制或能力。客户机通过事先分析MMS检索的SDP描述，能够制作匹配机制或能力的集合。这就解决了在服务器端的困惑，因为服务器不能清楚地知道在这种使用情景中的SDP描述内容。
III.在特定3GPSS会话中的SRTP使用
假设属性“SRTPSupport”定义于RDF模式符号集中，以信号指示定义于draft-srtp-05中的用于音频和视频媒体的SRTP支持。
假设属性“UnSupportedAdaptationSupport”作为匹配机制或能力被定义于RDF模式符号集中，该属性被客户机支持，但是不被服务器支持。
假设属性“SupportedAdaptationSupport”作为匹配机制或能力被定义于RDF模式符号集中，该属性也被服务器支持。
假设属性“x-srtpsupport”是明确定义的SDP属性，当SRTP被支持时，该属性包括在SDP的音频和视频(或在两种媒体类型中使用的会话层)媒体部分中。
假设“x-unsupportedadaptationsupport”是明确定义的SDP属性，当被支持时，该属性包括在SDP(会话或媒体层)中。
假设“x-supportedadaptationsupport”是明确定义的SDP属性，当被支持时，该属性包括在SDP(会话或媒体层)中。
A.通过可能的能力交换机制进行信号指示和协商：
-客户机发送带有指向客户机能力信息的URL的RTSP DESCRIBE请求给服务器，所述信息驻留于能力交换服务器上。
-服务器从能力交换服务器取客户机的能力声明。声明包括如图9所示的用于客户端流能力的一部分。在声明中的粗线表示客户机的匹配机制支持能力。当SRTPSupport为TRUE时，声明客户机具有对特定会话中的音频和视频媒体元件的SRTP支持。
-知道了这种能力之后，服务器制作要发送至客户机的SDP描述，该描述包括SRTP能力和SupportedAdaptationSupport能力。所述SDP描述显示于图10中。服务器不包括基于Unsupported AdaptationSupport的SDP属性，因为服务器并不支持该属性。
在SDP描述中的粗线指示SRTP的使用和对SupportedAdaptationSupport的支持。
-通过接收该SDP描述，客户机知道SRTP将用于音频和视频元件。客户机也知道UnsupportedAdaptationSupport将不被使用，并且SupportedAdaptationSupport机制或能力将用于音频和视频媒体。
B.通过可能的多媒体流控制协议进行信号指示和协商：
在3G PSS中，RTSP协议用于控制所述多媒体会话。
假设“x-srtpsupport”是明确定义的RTSP选择标签，它指示在客户机上的SRTP支持。
假设“x-unsupportedadaptationsupport”是明确定义的RTSP选择标签，当被客户机支持时，选择标签被信号指示于RTSP消息中。假定服务器不支持该标签所表示的机制或能力。
假设“x-supportedadaptationsupport”是明确定义的RTSP选择标签，当它被客户机支持时，选择标签被信号指示于RTSP消息中。
假定客户机知道用于多媒体会话的RTSP URL。
-客户机发送关于优选匹配机制或能力的选择的DESCRIBE请求：
客户机->服务器：
DESCRIBE rtsp：//foo/twister RTSP/1.0
CSeq：1
Require：x-srtpsupport，x-unsupportedadaptationsupport，x-supportedadaptationsupport
-客户机使用RTSP Require请求标题来信号指示所支持的机制或能力。
为了使服务器根据客户机支持的机制或能力成功地制作SDP，在RTSP描述方法之前或在RTSP描述方法中，RTSP请求中所支持的机制或能力由客户机信号指示。
-服务器检查RTSP请求并知道它能使用x-srtpsupport和x-supportedadaptationsupport，但不能使用x-unsupportedadaptationsupport。
服务器有两种可能的方式进行响应：
选择1：
-服务器发送RTSP 551“不支持的选择”响应，包括在消息体中不支持的机制或能力：
服务器->客户机
RTSP/1.0551不支持的选择
CSeq：1
Unsupported：x-unsupportedadaptationsupport
-客户机发布仅有支持的机制或能力的另一个DESCRIRE请求：
客户机->服务器：
DESCRIBE rtsp：//foo/twister RTSP/1.0
CSeq：2
Require：x-srtpsupport，x-supportedadaptationsupport
-服务器用RTSP 200OK消息来响应，也包含如图11所示的SDP描述。
选择2：
-服务器发送RTSP DESCRIBE响应，包含不支持的机制/能力信息，而没有使用RTSP 551状态响应。所述RTSP DESCRIBE响应如图12所示。
-服务器使用RTSP Unsupported响应标题来信号指示不可能用于特定会话的不支持的机制或匹配机制或能力，并使用适当的SDP属性来信号指示所选择的匹配机制或能力的使用。
-当客户机接收到采用SDP描述的DESCRIBE响应时，它知道哪些匹配机制或能力的集合被选择用于该特定会话。
在客户机诸如通过MMS接收到来自另一个源的SDP描述的情况下，客户机能够分析SDP描述并找到RTSP会话URL。然后，它发送RTSP DESCRIBE请求来信号指示和协商匹配机制或能力。通过事先分析MMS检索到的SDP描述，客户机能够制作匹配机制或能力的集合。这就解决了在服务器端的困惑，因为服务器不能清楚地知道在这种使用情景中的SDP描述内容。
总之，本发明提供了一种在多媒体流服务***中就数据传送过程的匹配方面在客户机和服务器之间进行信号指示和协商的方法。所述信号指示和协商过程可通过图13说明。如图13中的流程所示，为了协商匹配机制或能力，在步骤110，客户机向服务器信号指示多个客户机所具有的属性。这些属性是由客户机执行的那些匹配机制或能力。属性或者包括在为能力交换机制而定义的客户机的能力简档中，或者包括在为控制流会话而定义的多媒体流控制协议中。在步骤120，服务器获得来自能力简档或是多媒体流会活中的属性，并且选择这些属性的子集。在步骤130，基于所选择的属性，服务器制作多媒体会话描述并将所述描述发送到客户机。基于会话描述，客户机知道服务器选择的属性。在步骤140，缺省情况下，客户机接受由所选择的属性所定义的匹配机制或能力。按照本发明，所述信号指示和协商方法能够在特定3G PSS会话中的AVPT使用、RTP重传有用负荷格式使用或SPTP使用中被执行。
需要注意的是，也能够由服务器发起按照本发明的信号指示和协商的方法，如图14中的流程图所示。如图所示，在步骤210，服务器在没有客户机发起的情况下向客户机指示匹配机制或能力。在这种情况下，不存在来自客户端的匹配机制或能力的指示，但是存在来自服务器端的指示。在获得来自服务器的指示之后，在步骤220，客户机使用在RSTP响应中的明确定义的属性向服务器指示其对该能力的支持。
因此，尽管已经根据其中的优选实施例对本发明做了描述，但是本领域技术人员将容易理解，在不脱离本发明范围的情况下，可以在形式上和细节上对本发明进行前述的以及各种其它改变、省略以及偏离。
Claims (7)
1、一种在多媒体流服务中在客户机和服务器之间进行信号指示和协商的方法，其中所述客户机支持多个在数据传送服务中所使用的匹配机制或能力，每个匹配机制或能力具有属性，所述方法的特征在于：
所述客户机提供指明所述属性的信息，所述属性定义由所述客户机支持的所述匹配机制或能力；
所述服务器根据所提供的信息选择一个或多个属性；并且
所述服务器提供指明所述所选择属性的进一步信息，以便允许所述客户机知道一个或多个匹配机制或能力，所述匹配机制或能力由所述服务器所选择的一个或多个属性定义。
2、如权利要求1所述的方法，其特征在于，所述客户机通过能力交换机制来提供所述信息。
3、如权利要求1所述的方法，其特征在于，所属客户机通过多媒体流控制协议来提供所述信息。
4、如权利要求1所述的方法，其进一步的特征在于
所述服务器在所述客户机提供信息之前提供能力指示给所述客户机。
5、一种在多媒体流服务中在包括客户机和服务器的双方之间进行信号指示和协商的方法，其中所述客户机支持多个在数据传送服务中所使用的匹配机制或能力，每个匹配机制或能力具有属性，所述方法的特征在于：
由所述双方中的一方向另一方提供指明一个或多个匹配机制或能力的信息；
响应所述信息，由所述另一方传递消息给所述一方，确认对所述一个或多个匹配机制或能力的支持。
6、如权利要求5所述的方法，其特征在于，所述一方为服务器，另一方为客户机，并且
所述客户机通过在所述应答消息中使用定义所述一个或多个匹配机制或能力的属性来确认支持。
7、如权利要求5所述的方法，其特征在于，所述一方为客户机，另一方可能是服务器，并且
所述客户机提供多个属性，并且
所述服务器基于所提供的信息来选择一个或多个所提供的属性，用于确认所述支持。
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US44726403P | 2003-02-13 | 2003-02-13 | |
| US60/447,264 | 2003-02-13 | ||
| US60/448,309 | 2003-02-14 | ||
| US60/448,284 | 2003-02-14 | ||
| US60/448,229 | 2003-02-14 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN1751304A true CN1751304A (zh) | 2006-03-22 |
Family
ID=36606031
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN 200480004196 Pending CN1751304A (zh) | 2003-02-13 | 2004-02-13 | 在多媒体流中用于信号指示流质量匹配和控制机制的方法 |
| CN 200480004195 Pending CN101088081A (zh) | 2003-02-13 | 2004-02-13 | 在多媒体流中用于发信号报告客户机速率能力的方法 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN 200480004195 Pending CN101088081A (zh) | 2003-02-13 | 2004-02-13 | 在多媒体流中用于发信号报告客户机速率能力的方法 |
Country Status (2)
| Country | Link |
|---|---|
| CN (2) | CN1751304A (zh) |
| ZA (1) | ZA200506682B (zh) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101573941B (zh) * | 2006-12-29 | 2013-02-06 | 艾利森电话股份有限公司 | 用于交叉参考相关应用来报告流媒体质量的方法和设备 |
| CN103081505A (zh) * | 2010-09-02 | 2013-05-01 | 三星电子株式会社 | 用于产生控制包的方法和设备 |
| US8566395B2 (en) | 2009-09-21 | 2013-10-22 | Huawei Technologies Co., Ltd. | Method and apparatus for transmitting hypertext transfer protocol media |
| CN101803409B (zh) * | 2007-06-19 | 2014-06-25 | 诺基亚公司 | Mbms向pss切换的***和方法 |
| CN106953834A (zh) * | 2016-01-07 | 2017-07-14 | ***通信集团公司 | 一种实现终端媒体能力协商的方法、终端及网络设备 |
| CN107846567A (zh) * | 2017-11-02 | 2018-03-27 | 苏州科达科技股份有限公司 | 一种srtp能力协商方法及会议终端 |
| CN112270488A (zh) * | 2020-11-09 | 2021-01-26 | 中国电子技术标准化研究院 | 无人机集群任务分配方法、装置及无人机集群*** |
-
2004
- 2004-02-13 CN CN 200480004196 patent/CN1751304A/zh active Pending
- 2004-02-13 CN CN 200480004195 patent/CN101088081A/zh active Pending
-
2005
- 2005-08-19 ZA ZA200506682A patent/ZA200506682B/en unknown
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101573941B (zh) * | 2006-12-29 | 2013-02-06 | 艾利森电话股份有限公司 | 用于交叉参考相关应用来报告流媒体质量的方法和设备 |
| CN101803409B (zh) * | 2007-06-19 | 2014-06-25 | 诺基亚公司 | Mbms向pss切换的***和方法 |
| US8566395B2 (en) | 2009-09-21 | 2013-10-22 | Huawei Technologies Co., Ltd. | Method and apparatus for transmitting hypertext transfer protocol media |
| CN102025760B (zh) * | 2009-09-21 | 2015-11-25 | 华为技术有限公司 | Http的媒体传输方法及装置 |
| CN103081505A (zh) * | 2010-09-02 | 2013-05-01 | 三星电子株式会社 | 用于产生控制包的方法和设备 |
| CN103081505B (zh) * | 2010-09-02 | 2017-05-31 | 三星电子株式会社 | 用于产生控制包的方法和设备 |
| CN106953834A (zh) * | 2016-01-07 | 2017-07-14 | ***通信集团公司 | 一种实现终端媒体能力协商的方法、终端及网络设备 |
| CN106953834B (zh) * | 2016-01-07 | 2020-01-24 | ***通信集团公司 | 一种实现终端媒体能力协商的方法、终端及网络设备 |
| CN107846567A (zh) * | 2017-11-02 | 2018-03-27 | 苏州科达科技股份有限公司 | 一种srtp能力协商方法及会议终端 |
| CN107846567B (zh) * | 2017-11-02 | 2020-12-29 | 苏州科达科技股份有限公司 | 一种srtp能力协商方法及会议终端 |
| CN112270488A (zh) * | 2020-11-09 | 2021-01-26 | 中国电子技术标准化研究院 | 无人机集群任务分配方法、装置及无人机集群*** |
| CN112270488B (zh) * | 2020-11-09 | 2023-12-12 | 中国电子技术标准化研究院 | 无人机集群任务分配方法、装置及无人机集群*** |
Also Published As
| Publication number | Publication date |
|---|---|
| ZA200506682B (en) | 2006-05-31 |
| CN101088081A (zh) | 2007-12-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1933478A (zh) | 媒体流打包时长协商方法 | |
| CN1846420A (zh) | 嵌入的服务质量相关信息的传送 | |
| CN1859562A (zh) | 视频点播方法、***、服务器和终端 | |
| CN101052154A (zh) | Ip多媒体子***及其编解码转换控制方法 | |
| CN1723452A (zh) | 传输和下载流数据的方法 | |
| CN1917649A (zh) | 一种支持多音轨的方法、***及流媒体服务器 | |
| CN1832473A (zh) | 一种在ims网络中处理会话消息的方法及装置 | |
| CN101031061A (zh) | 元数据产生设备、信息处理设备、成像设备及安全*** | |
| CN1841984A (zh) | 通信处理装置、数据通信***以及通信处理方法 | |
| CN101047711A (zh) | Ip报文传输、协商带宽节省能力和节省网络带宽的方法 | |
| CN1661990A (zh) | 协议版本转换器 | |
| CN1665324A (zh) | 架构即按即说通信连结及即按即说客户单元的方法及通信装置 | |
| CN1852431A (zh) | 实现实时视频信息共享的***及方法 | |
| CN1859380A (zh) | 一种离线消息获取方法 | |
| CN1204504C (zh) | 文件传送***、中继设备、和文件传送方法 | |
| CN1754159A (zh) | 信息处理装置和内容信息处理方法 | |
| CN1859123A (zh) | 一种动态内容续传方法及*** | |
| CN1839580A (zh) | 信息分配*** | |
| CN1838642A (zh) | 利用即时消息***实现问答业务的方法及*** | |
| CN1946087A (zh) | 移动终端与服务器端之间的数据传输方法及*** | |
| CN101064863A (zh) | 一种ims网络下提供媒体资源服务的方法和*** | |
| CN1889586A (zh) | 一种注册/注销***和注册/注销方法 | |
| CN1859395A (zh) | Ip多媒体子***业务实现***和方法 | |
| CN1751304A (zh) | 在多媒体流中用于信号指示流质量匹配和控制机制的方法 | |
| CN101047524A (zh) | 实现多媒体录制的方法及*** |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Open date: 20060322 |