专利名称：一种高效的按键通话方法
技术领域：
本发明涉及通讯领域，特别是涉及一种基于的移动通信网络分组域的会话协商和音频媒体数据传输的领域。
背景技术：
SIP是一个应用层的信令控制协议。用于创建、修改和释放一个或多个参与者的会话。这些会话可以好似Internet多媒体会议、IP电话或多媒体分发。会话的参与者可以通过组播(multicast)、网状单播(unicast)或两者的混合体进行通信。SIP它既不是会话描述协议，也不提供会议控制功能。为了描述消息内容的负载情况和特点，SIP使用Internet 的会话描述协议(SDP)来描述终端设备的特点。SIP自身也不提供服务质量(QoS)，它与负责语音质量的资源保留设置协议(RSVP)互操作。
在进行实时传输媒体数据时，使用RTP协议与SIP合作使用。RTCP控制协议需要与RTP数据协议一起配合使用，RTP本身并不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。通常RTCP会采用与RTP相同的分发机制，向会话中的所有成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控制或者对网络状况进行诊断。
在现在的OMA规范中PoC业务就是使用的SIP加RTP/RTCP的方案，SIP用于会话的协商，RTP/RTCP用于流媒体数据的传输。
对于PoC业务的使用场景主要在通话比较频繁的地方或者偏僻的郊外，如行业用户中的电力、物流、水 利等，这些地方偏僻、流动性大，不可能有专用网络，接入方式使用最多的就是现在覆盖比较好的移动通信网络，所以3G分组域接入成了最常用的接入方式。
在现有的产品中，受限于带宽、PDP激活时长等的限制导致会话建立时间太长、语音延时明显的问题，分析其原因主要是由几个方面引起，一个是PDP激活的时长，这个由移动网络决定不在此讨论。一个是通过SIP协议做会话协商的时间太长，由于SIP协议数据量太大，做会话协商需要的时间比较长。另外一个是做媒体流传输的包太小，导致传输中有大量的包头数据和建立连接次数太多消耗时间，本发明就是针对后两个问题做优化来减少按键通话的会话建立延时和传输效率地下。发明内容
本发明所要解决的技术问题是在原有RTCP协议的基础上作了如下改进，使用RTP 协议进行媒体数据传输，RTCP协议在实现本身功能的同时进行扩展，使其同时能够完成会话协商的功能来替代SIP会话协商；并对传输的媒体包进行打包处理使相同时间发送的包的数量最少。
为实现上述发明目的，本发明提供一个重新封装的RTP/RTCP协议库，及对应的 PoC服务器，包括PoC客户端和PoC服务器
所述PoC客户端，用于最终用户使用，手机终端中的PoC软件通过移动通讯网络的分组域连接，注册使用SIP消息在服务器中注册，移动通讯网络分组域连接为了节约资源， 防止没有数据的空连接太多都设置了连接时长限制，在一段时间内如果没有数据传输就会断开连接，所以客户端软件在注册成功后为了维持连接需要发送心跳消息，心跳消息的间隔时长根据不同地方的网络设置有区别，心跳消息是通过RTP和RTCP消息发送，发送IDLE 消息，不作其他功能，只是维持连接使用。根据用户的操作发起对PoC联系人的按键通话操作，发起呼叫的主叫方通过RTCP的格式和通道，把RTCP包的APP字段特殊定义成204， subtype字段定义成不同的会话控制请求类型，把NAME定义成“PoCl”，这样整个会话协商功能的包就完成了，通过RTCP通道发送，并通过接受RTCP通道的消息来完成会话协商，这样在；
所述PoC服务器，用于对PoC客户端服务，支撑PoC业务的使用。
本发明还提供一套打包和解包的方法，包括
1.本系统使用AMR编码格式5. 15kbps的比特率，这个比特率对于人说话的声音清晰度是够用的，音频数据采集是20ms —组数据，在编码后一组数据是13字节，在对音频数据打包处理时不是一组数据一发，而是采用8组数据编码完成后组合在一起发送，这样处理主要考虑两方便，一个是数据不能太短，太短发送频率太大，这样建立连接和包头数据冗余太多，影响发送效率；数据不能太长，太长后延时就长，另外要一个分组域的包能发送完成，如果分包处理就会有延时。
2.解包时，服务器或客户端会先根据收到包的长度，来判断该包构成，然后再解包恢复媒体数据。
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施中消息控制图2为本发明实施中的媒体数据组包发送格式。
具体实施方式
为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式
对本发明作进一步详细的说明。显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明提供一个重新封装的RTP/RTCP协议库，其中改进点包括
RTCP是发言权控制协议，是基于RTCP应用包的(RTCP = APP)，与其他的RTCP包发送到相同的UDP端口。
RTCP定义的控制TBCP消息包括
· TBCP Talk Burst Request-客户端向服务器端请求发言权允许
表I “TBCP Talk Burst请求消息”说明了消息的内容。0123 01234567890123456789012345678901|V=2|P|0 O O O 0| PT=APP=204 丨lengthH—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I1SSRC of PoC Client requesting permission to send a talk burstIname=PoClI Option ID I Option Length I IOption ValueI Option ID I Option Length 丨 Option Value
在Subtype域中的下列比特格式应该被用来作为TBCP Talk Burst请求信息00000。SSRC域应该携带申请发言权的PoC用户的SSRC值。在TBCP Talk Burst请求消息中，可以包含一个或多个可选域。每个TBCPTalk Burst请求消息可选域应该包含三个子域。
第一个子域是可选ID子域。这个可选ID子域应该标识选来作为8-bit可选ID 的选项。
第二个子域是可选长度子域。可选长度子域应该由一个字节组成，说明整个可选域的长度。可选长度子域的值应该等于可选ID子域、可选长度子域和可选值子域字节数的总和。
注意这个长度没有必要乘以4。
第三个子域是可选值子域。这个值子域应该包含一个字节数的整数值。这个子域的格式和值是依赖于应用选项的。
下面的定义了 TBCP Talk Burst请求信息选项
如果PoC服务器收到重复的TBCP Talk Burst request，PoC服务器按照正常的处理方法处理请求。
] TBCP Talk Burst Granted-服务器端通知客户端允许其讲话表2 “TBCP Talk Burst允许消息”显示了消息的内容。
[003权利要求
1.一种基于RTCP的无线对讲通讯系统会话控制协议，其特征在于，使用封装好的RTCP 协议进行扩展来代替SIP协议控制会话状态。
2.根据权利要求1所述的方法，其特征在于，还包括使用RTCP协议作为控制信号传输的协议，使用RTCP协议作为媒体流传输的协议；定义的RTCP信号包括CONNECT， DISCONNECT, ACK, GRANTED, REQUEST, RELEASE, IDLE。
3.一种基于MS的无线对讲通讯系统媒体传输格式的优化，其特征在于，降低RTP协议包的传输频率，提高传输效率。
4.根据权利要求3所述的方法，其特征在于，还包括按照20ms—个音频采集编码数据包来打包数据,然后每次把多个(现在使用8个)相邻包的数据合成一个包传输出去(现在使用的8个包打包，传输周期为160ms)。
全文摘要
本发明公开了一种按键通话中呼叫建立的时间太长的问题的解决方案。针对现有OMA的PoC(push to talk over celluler)规范中首次呼叫建立延时、通话延时时间比较长的问题，对会话控制协议进行修改后传输的呼叫控制协议数据量减少，并对音频数据进行打包传输，达到减少延时的目的。
文档编号H04W4/10GK103024681SQ201110282500
公开日2013年4月3日 申请日期2011年9月20日 优先权日2011年9月20日
发明者梁平, 李大军, 宁学军 申请人:佳都新太科技股份有限公司