专利名称：一种提高无线流媒体系统连接速度的方法
一种提高无线流媒体系统连接速度的方法
技术领域：
本发明涉及移动通信技术，特别涉及一种提高无线流媒体系统连接速度的 方法。
背景技术：
随着3G时代的到来，其重要应用之一的移动视频通信领域将会越来越多受 到人们的关注，而视频通信中的流媒体业务也成为受注度和使用率最高的业务。 目前，基于RTSP协议的流媒体应用发展迅速，在Internet上传输流媒体的相关 技术成为热点。
现有技术中标准的、友好的RTSP流程要经过图l所示的六个过程，考虑到 最后的一个交互过程是停止播放时的交互，那么播放一个节目的交互过程也多 达五个。在有线的IP网络环境下，网络延迟一般为毫秒级，完成这五个交互过 程一般会少于三秒，在用户可以接受的范围之内，并且不会影响用户的体验效 果。但是无线网络环境下的网络延迟在秒级，如目前的GPRS网络，其传输数据 的延时为秒级范围。在绝大部分时间下，GPRS数据通信的平均整体延时为2秒 左右。也就是说，从GPRSDTU端发送的数据包将大致在2秒钟后到达数据中心。 反之，从数据中的数据包也大致在2秒钟后到达GPRS DTU。如果网络延迟为1 秒的话，完成这五个交互过程的时间就需要10秒，严重影响用户的使用及体验 效果。本专利提出一种改进的rtsp交互方法，设法减少rtsp在无线网络中的 交互次数，减少总的建立连接时间，从而提高用户体验效果。
Real Time Streaming Protocol或者RTSP (实时流媒体协议)，是解决如 何有效地在IP网络上传输流媒体数据的应用层协议。RTSP提供一种可扩展的框 架，使能够提供能控制的，按需传输实时数据，比如音频和视频文件。源数据 可以包括现场数据的反馈和存贮的文件。rtsp对流媒体提供了诸如暂停，快进 等控制，而它本身并不传输数据，rtsp作用相当于流媒体服务器的远程控制。 传输数据可以通过传输层的tcp， iidp协议，rtsp也提供了基于rtp传输机制的 一些有效的方法。图1中的交互过程的具体实例化如下
RTSP消息格式
RTSP的消息有两大类， 一是请求消息(request)， 一是回应消息(response)，两种
消息的格式不同.
请求消息
方法URI RTSP版本CR LF 消息头CR LF CR LF 消息体CR LF RTSP交互方法
1、 OPTION
目的是得到服务器提供的可用方法
OPTIONS rtsp:〃192. 168. 20. 136:5000/xxx666 RTSP/1. 0
CSeq: 1 〃每个消息都有序号来标记，第一个包通常是option
请求消息
User-Agent: QTS .. qtver=6. 5. 1.. os二Windows NT 5. IService Pack 2..
服务器的回应信息包括提供的一些方法，例如 RTSP/1. 0 200 OK Server: UServer 0. 9. 7_rcl
Cseq: 1 〃每个回应消息的cseq数值和请求消息的cseq相对
应
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN， PLAY, PAUSE, SCALE, GET—PARAMETER 〃服务器提供的可用的方法
2、 DESCRIBE
Client向Server发起DESCRIBE请求，为了得到会话描述信息(SDP): DESCRIBE rtsp:〃192. 168. 20. 136:5000/xxx666 RTSP/1. 0 CSeq: 2 token:
Accept: 邻plication/sdp
User—Agent: QTS .. qtver二6. 5. 1. . os=Windows NT 5. IService Pack 2..服务器回应一些对此会话的描述信息(sdp):
RTSP/1.0 200 OK
Server: UServer 0. 9. 7—rcl
Cseq: 2
x-prev-url: rtsp://192.168. 20. 136:5000
x-next-url: rtsp://192.168. 20. 136:5000
x—Accept—Retransmit: our-retransmit
x-Accept-Dynamic-Rate: 1
Cache-Control: must-revalidate
Last-Modified: Fri， 10 Nov 2006 12:34:38 GMT
Date: Fri， 10 Nov 2006 12:34:38 GMT
Expires: Fri， 10 Nov 2006 12:34:38 GMT
Content—Base: rtsp:〃192. 168. 20. 136:5000/xxx666/
Content—Length: 344
Content—Type: application/sdp
v=0 〃以下都是sdp信息
o=0newaveUServerNG 1451516402 1025358037 IN IP4 192.168. 20. 136
s=/xxx666
u=http:/〃
e=admin@
c=IN IP4 0. 0. 0. 0
t=0 0
a=isma—compliance: 1， 1. 0, 1 aFmnge:叩t二O-
m二video 0 RTP/AVP 96 〃m表示媒体描述，下面是对会话中视频通道 的媒体描述
a=rtpmap:96 MP4V-ES/90000 a=fmtp:96
profile-level-id=245;config=000001B0F5000001B509000001000000012000C888B0E0E0FA62D089028307
a二control:trackID二O 〃tracklD二0表示视频流用的是通道0
3、 SETUP
Client提醒Server建立会话，并确定传输模式
SETUP rtsp:〃192. 168. 20. 136:5000/xxx666/trackID=0 RTSP/1. 0 CSeq: 3
Transport: RTP/AVP/TCP;unicast;interleaved二O-l
User-Agent: QTS . . qtver=6. 5. 1. . os二Windows NT 5. IService Pack 2..
服务器回应信息 RTSP/1. 0 200 OK Server: UServer 0.9.7—rcl Cseq: 3
Session: 6310936469860791894 〃服务器回应的会话标识符 Cache—Control: no-cache
Transport: RTP/AVP/TCP; unicast; interleaved^-1; ssrc=6B8B4567
4、 PLAY
客户端发送播放请求
PLAY rtsp:〃192. 168. 20. 136:5000/xxx666 RTSP/1. 0 CSeq: 4
Session: 6310936469860791894
Range: npt=0. 000- 〃设置播放时间的范围
User—Agent: QTS .. qtver=6. 5. 1. . os=Windows NT 5. IService Pack 2..
服务器回应信息 RTSP/1. 0 200 OK Server: UServer 0.9.7—rcl Cseq: 4
Session: 6310936469860791894 Range: npt=0. -RTP-Info: url=trackID=0;seq=17040;rtptime=1467265309 〃seq 和rtptime都是rtp包中的信息
5、 TEA訓丽 客户端发起关闭请求
TEARDO丽rtsp:〃192. 168. 20. 136:5000/xxx666 RTSP/1. 0 CSeq: 5
Session: 6310936469860791894
User-Agent: QTS . . qtver二6. 5. 1. . os=Windows NT 5.IService Pack 2..
服务器回应
RTSP/1. 0 200 OK
Server: UServer 0. 9. 7—rcl
Cseq: 5
Session: 6310936469860791894 Connection: Close
由以上来回多个交互过程，将大大增加网络延迟时间，鉴于此，实有必要 提出一种新的技术方案。
发明内容
本发明目的在于，提出一种改善手机端点播流媒体服务器连接速度的方案，
能够加快手机端连接流媒体服务器的速率，及提高用户的体验效果。
为了实现以上目的，本发明一种提高无线流媒体系统连接速度的方法，所 述流媒体系统包括客户端与服务器，所述方法基于RTSP协议传输数据，其特征
在于，所述方法如下
Al :客户端向服务端发起DESCRIBE请求，以获取会话描述信息SDP， A2:服务器向客户端回应对此会话的描述信息； Bl:客户端向服务端发送的改进后的PLAY请求， B2:服务器和客户端回应改进后的PLAY信息。相对现有技术，减少了网络延迟时间，从而縮短用户的等待时间，极大的 提高了用户的体验效果。
图1为现有技术中标准的、友好的RTSP流程交互过程示意图2为本发明方法RTSP流程交互过程示意图。
具体实施方式
从现有技术的交互过程可以看到，OPTION这个方法只是提供一个查询功 能，服务器告诉客户端有哪些可用的方法，为了适应无线中的延时大的特点， 在本发明方法中流媒体服务器应用于无线网络时省略OPTION这个方法。 DESCRIBE这个方法是建立会话及得到媒体的一些信息，包含客户端要播放的媒 体文件的一些信息，这个过程是必须的。
SETUP这个方法是建立会话及传输方法，并且音频视频需要二次交互过程。 PLAY方法用于通知服务器开始播放媒体。考虑到无线网络的实际情况，在本发 明方法中将SETUP这个方法是建立会话及传输方法，并且音频视频需要二次交 互过程以及PLAY方法的交互过程三个交互过程整合起来，用一个交互来完成上 述三个方法的功能。具体如下
客户端在收到DESCRIBE方法的回应包后立即发送改进过的PLAY方法，在 PLAY这个方法中包含客户端要播放的媒体的trackID (位置信息)，媒体包括视 频与音频，或是其中的任意一个，视频与音频的会话信息不再分开发送，而是 一起发送。PLAY方法中还包括传输的模式及起始播放的时间。在流媒体服务器 的回应信息中则包含对传输模式的确认及媒体数据的会话通道，媒体数据包中 的起始序列号与媒体数据包的中起始时间戳，其中媒体包括视频与音频，或是 其中的任一个，视频与音频的会话信息不再分开发送。
经过上述方法改进后，客户端与服务器的实际交互过程如图2。 改进后的RTSP交互过程 改进后的PLAY命令 客户端发送的改进后的PLAY请求PLAY rtsp://192. 168.20. 136:5000/xxx666/tracklDO; trackID=l RTSP/1. 0 CSeq: 4
Session: 6310936469860791894
Range: npt=0. 000- 〃设置播放时间的范围
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
User-Agent: QTS .. qtver=6. 5. l…os二Windows NT 5. IService Pack 2…
服务器回应改进后的PLAY信息 RTSP/1. 0 200 OK Server: UServer 0. 9. 7—rcl Cseq: 4
Session: 6310936469860791894 Range: npt=0.OOOOOO-
RTP-Info:url=trackID=0;seq=17040;rtpt ime=1467265309;url=trackID=l;se q=l; rtptime=0〃seq禾口 rtptime都是rtp包中的信息 Transport: RTP/AVP/TCP;unicast;interleaved二0-1;ssrc二6B8B4567
相对于图1中的现有技术，具体对本发明图2所示的方法交互过程示意图 作一个实例化如下
1、 DESCRIBE
Client向Server发起DESCRIBE请求，为了得到会话描述信息(SDP): DESCRIBE rtsp:〃192. 168. 20. 136:5000/xxx666 RTSP/1. 0 CSeq: 2 token:
Accept: application/sdp
User-Agent: QTS . . qtver=6. 5. 1. . os二Windows NT 5. IService Pack 2..
服务器回应一些对此会话的描述信息(sdp):
RTSP/1. 0 200 OK
Server: UServer 0. 9. 7一rcl
Cseq: 2x-next-url: rtsp://192. 168. 20. 136:5000
x-Accept—Retransmit: our-retransmit
x-Accept-Dynamic—Rate: 1
Cache-Control: must-revalidate
Last-Modified: Fri， 10 Nov 2006 12:34:38 GMT
Date: Fri, 10 Nov 2006 12:34:38 GMT
Expires: Fri， 10 Nov 2006 12:34:38 GMT
Content-Base: rtsp:〃192. 168. 20. 136:5000/xxx666/
Content-Length 344
Content-Type: 即plication/sdp
v二0 〃以下都是sdp信息
o=0newaveUServerNG 1451516402 1025358037頂IP4 192.168.20. 136
s=/xxx666
u=hUp:〃/
e=admin@
c=IN IP4 0. 0. 0. 0 t=0 0
a二isma-compliance: 1， 1.0， 1
m=Video 0 RTP/AVP 96 〃m表示媒体描述，下面是对会话中视频通道 的媒体描述
a二rtpmap:96 MP4V-ES/90000 a=fmtp:96
profile-level-id=245;config=000001B0F5000001B50900000100000001 2000C888B0E0E0FA62D089028307
a=control:trackID=0 〃trackID=0表示视频流用的是通道O 2、 PLAY
客户端发送的改进后的PLAY请求PLAY rtsp:〃192. 168. 20. 136:5000/xxx666/tracklDO; trackID二l
RTSP/l. 0 CSeq: 4
Session: 6310936469860791894
Range: npt=0. 000- 〃设置播放时间的范围
Transport: RTP/AVP/TCP;unicast;interleaved二O-l
User-Agent: QTS .. qtver=6. 5. 1. . os=Windows NT 5. IService Pack 2..
服务器回应改进后的PLAY信息 RTSP/l. 0 200 OK Server: UServer 0. 9. 7_rcl Cseq: 4
Session: 6310936469860791894 Range:叩t二O. 000000-
RTP-Info:url=trackID=0;seq=17040;rtptime=1467265309;url=trackl D=l; seq=l; rtptime二O〃seq禾口 rtptime都是rtp包中的信息 Tran印ort: RTP/AVP/TCP; unicast; interleaved=0-1; ssrc二6B8B4567
3、 TEARDO丽 客户端发起关闭请求
TEARDOWN rtsp:〃192. 168. 20. 136:5000/xxx666 RTSP/l. 0 CSeq: 5
Session: 6310936469860791894
User—Agent: QTS . . qtver=6. 5. 1. . os二Windows NT 5.IService Pack 2..
服务器回应
RTSP/l. 0 200 OK
Server: UServer 0.9.7_rcl
Cseq: 5
Session: 6310936469860791894
12Connection: Close
经过本文所述的方法改进后，把目前的RTSP六个交互过程縮减为三个，不 考虑播放结束时的交互过程的话(因为这个交互过程不会影响到用户开始播放 时的等待时间)，那改进后的交互过程就尽有二个，如果网络延迟为l秒的话， 只需要4秒就能完成流媒体服务器与客户端的交互，如果网络延迟为0.5秒的 话，这个过程就会縮减为2秒，从而縮短用户的等待时间，极大的提高了用户 的体验效果。
在上述实施例中，仅对本发明进行了示范性描述，但是本领域技术人员在 不脱离本发明所保护的范围和精神的情况下，可根据不同的实际需要设计出各 种实施方式。
权利要求
1.一种提高无线流媒体系统连接速度的方法，所述流媒体系统包括客户端与服务器，所述方法基于RTSP协议传输数据，其特征在于，所述方法如下A1客户端向服务端发起DESCRIBE请求，以获取会话描述信息SDP，A2服务器向客户端回应对此会话的描述信息；B1客户端向服务端发送的改进后的PLAY请求，B2服务器和客户端回应改进后的PLAY信息。
2、 如权利要求1所述的提高无线流媒体系统连接速度的方法，其特征在于所述发送的改进后的PLAY请求以及回应改进后的PLAY信息称为改进后的PLAY方法为，该改进后的PLAY方法如下将SETUP方法的音频视频需要二次交互过程以及PLAY方法的交互过程三个交互过程整合起来，合并为一个交互来完成上述三个方法的功能，其中所述SETUP方法是建立会话及传输方法。
3、 如权利要求1所述的提高无线流媒体系统连接速度的方法，其特征在于所述方法还包括CI:客户端发起关闭请求，C2:服务端回应关闭请求。
4、 如权利要求1所述的提高无线流媒体系统连接速度的方法，其特征在于-客户端在收到DESCRIBE方法的回应包后立即发送改进过的PLAY方法，在PLAY这个方法中包含客户端要播放的媒体的trackID即位置信息，媒体包括视频与音频，或是其中的任意一个，视频与音频的会话信息不再分开发送，而是一起发送。
5、 如权利要求2所述的提高无线流媒体系统连接速度的方法，其特征在于所述PLAY方法中还包括传输的模式及起始播放的时间。在流媒体服务器的回应信息中则包含对传输模式的确认及媒体数据的会话通道，媒体数据包中的起始序列号与媒体数据包的中起始时间戳，其中媒体包括视频与音频，或是其中的任一个，视频与音频的会话信息不再分开发送。
6、如权利要求1所述的提高无线流媒体系统连接速度的方法，其特征在于: 网络延迟时间为1秒，则二个交互过程累积的网络延迟时间为4秒。
全文摘要
本发明涉及一种提高无线流媒体系统连接速度的方法，所述流媒体系统包括客户端与服务器，所述方法基于RTSP协议传输数据，其特征在于，所述方法如下A1客户端向服务端发起DESCRIBE请求，以获取会话描述信息SDP；A2服务器向客户端回应对此会话的描述信息；B1客户端向服务端发送的改进后的PLAY请求，B2服务器和客户端回应改进后的PLAY信息。C1客户端发起关闭请求，C2服务端回应关闭请求。
文档编号H04W76/02GK101662839SQ200910190138
公开日2010年3月3日 申请日期2009年9月9日 优先权日2009年9月9日
发明者邹联忠 申请人:深圳市融创天下科技发展有限公司