专利名称：一种实现确认PoC业务接收效果的方法
技术领域：
本发明涉及PoC(PTT over cellular)技术领域，特别是指一种实现确认PoC业务接收效果的方法。
背景技术：
PTT(Push to Talk)是一种即按即说的语音业务，即通过按住功能键实现通信的一种半双工语音业务，目前该业务有很多种实现方式，如集成数字增强网络(iDEN)业务以及陆地中继无线电技术(Tetra)业务等。
PoC(PTT over cellular)是开放移动联盟组织(OMA，open mobilealliance)定义的在分组网络上实现的PTT业务，其采用分组语音(VoIP)以及半双工的实现方式，能够低成本、高效率地满足用户实时通信的需求。PoC业务具有如下特点1)通话时不需要拨号，按住特殊键即可实现语音通信；2)能够实现组播功能，即一个用户说话时多个用户同时收听；3)组播业务的群组可以是预先定义的，也可以是临时定义的；4)在通话过程中采用半双工模式，被叫用户在接听时不能发言；5)用户一直在线，建立通话的时间短，其快于拨号；PoC业务引入了一种新的通信模式，是现有移动系统以及传统语音呼叫系统所无法提供的，PoC在满足实时呼叫的同时，能够较少地占用系统资源。
图1所示为PoC业务开展模式图。具有PoC能力终端的用户与PoC业务的供应商进行签约，以获得使用PoC业务的许可；PoC用户通过PoC服务器与其它PoC用户建立群组关系；PoC用户通过按功能键要求发言从而实现PoC业务。
假设客户端A(ClientA)申请注册完毕后，接收到已注册的ClientB发出的建立连接的邀请，则在ClientB与ClientA之间建立起用户面承载后，即可开始会话。图2所示为实现PoC业务的流程图。
步骤201，ClientA通过SIP核心网(SIP core)向PoC服务器(PoC Server)发送SIP注册请求消息，该请求消息中包括鉴权信息和参数协商信息；步骤202，SIP core完成对ClientA的鉴权后，向ClientA发送200OK确认消息；步骤203，当ClientB希望与ClientA进行会话时，首先向PoC server发送邀请(invite)消息，邀请ClientA与PoC server建立连接；步骤204，PoC server通过SIP core将邀请消息转发给ClientA；步骤205，ClientA接收到邀请消息后，通过SIP core将200OK发送给PoC server；步骤206，PoC server接收到来自ClientA的200OK信息后，将该信息转发给ClientB；步骤207，ClientB向PoC server回复响应消息；步骤208，PoC server将来自ClientB的响应消息通过SIP core转发给ClientA；步骤209，ClientA接收到来自ClientB的响应消息后，与PoC server建立Client面承载，此时，ClientA与ClientB之间可通过PoC server建立会话连接。
目前根据OMA的定义，PoC用户只能进行半双工的语音业务即用户在收听时不能够发言，发言时需要先申请，获得发言权后，才能进行发言，但发言的同时不能接收其它用户的发言。
现有的PoC虽然满足了用户对于PTT业务的基本需求，但如果一个用户对一个群组发送会话后，由于网络覆盖或者其他原因，希望确认所有或部分接听客户端的接收效果时，根据现有方案首先需要发言用户完成发言后，通过语音要求接听用户确认是否正确收到信息，而被要求的接听用户只能通过按功能键抢占发言的方式，来通知发言客户端其自身的接听效果。这样不但会对系统造成很大的冲击，而且这种确认方式也让发言客户端无法方便、准确地记录下确认信息，从而给业务的应用带来了很大的不便。
发明内容
有鉴于此，本发明的目的在于提供一种实现确认PoC业务接听效果的方法，既能够便于发言者记录确认信息，又能避免由于很多用户抢占发言权而对系统造成的冲击。
为达到上述目的，本发明的技术方案是这样实现的一种实现确认PoC业务接收效果的方法，该方法包括以下步骤a、发言客户端在发送报告消息SR中设置要求接听客户端发送接收报告消息的标识信息；b、发言客户端在发言结束后请求PoC服务器将SR消息转发给接听客户端；c、接听客户端接收到PoC服务器转发的SR报文后，根据该消息中的接收报告消息的标识信息判断自身是否需要发送RR报文，如果是，则向PoC服务器发送RR报文后，执行步骤d，否则不做任何处理；d、根据接听客户端所发送的RR报文，发言客户端确认接听客户端的接收效果。
较佳地，步骤c所述接听客户端判断自身是否需要发送RR报文的方法包括以下步骤c1、根据SR报文中的接收报告消息的标识信息判断是否要求所有的接听客户端发送RR报文，如果是，则向PoC服务器发送RR报文，否则执行步骤c2；c2、判断是否要求部分接听客户端发送RR报文，如果不是，则不需要自身发送RR报文，如果是，则进一步判断需要发送RR报文的用户名中是否包含自身的用户名，如果是，则向PoC服务器发送RR报文，否则不需要自身发送RR报文。
较佳地，步骤d所述根据接听客户端所发送的RR报文，发言客户端确认接听客户端接收效果的方法是发言客户端接收到PoC服务器转发的RR报文后，首先判断所接收到的报文是否属于本次发言的语音包，如果是，再根据接收到的RR报文计算出丢包率和到达间隔抖动时间确认各个发送RR报文的接听客户端的接收效果。
较佳地，所述PoC服务器给发言客户端转发RR报文的方法是PoC服务器接收到来自接听客户端的RR报文后，首先进行缓存，然后再按照RTCP协议的定义，将所收集到的RR报文组装成一个RR报文后，发送给发言客户端。
较佳地，所述缓存的方式为PoC服务器每隔一段已设定的时间发送一次已组装的RR报文，或者，每收集到已设定个数的RR报文，发送一次已组装的RR报文。
较佳地，所述发言客户端判断所接收到的报文是否属于本次发言的语音包的方法是根据RR报文中的extended highest sequence number received字段判断该RR报文是否属于本次发言所产生的语音包的序号范围之内，如果是，则属于本次发言所产生的语音包，否则，不属于本次发言所产生的语音包。
较佳地，步骤d所述根据接听客户端所发送的RR报文，发言客户端确认接听客户端的接收效果的方法是由PoC服务器根据来自接听客户端的RR报文计算出各个发送RR报文的接听客户端的丢包率和到达间隔抖动时间，并将已计算出的丢包率和到达间隔抖动时间转换为接收质量等级发送给发言客户端，由发言客户端根据该接收质量等级确认各个发送RR报文的接听客户端的接收效果。
较佳地，该方法进一步包括发言客户端提示发言用户向接收效果较差的接听客户端重新发送语音包。
本发明由发言客户端在发送报告消息SR中设置要求接听客户端发送接收报告消息的标识信息，发言客户端在发言结束后请求PoC服务器将SR消息转发给接听客户端；接听客户端接收到PoC服务器转发的SR报文，根据该报文中的接收报告消息的标识信息判断出自身需要发送RR报文后，再向PoC服务器发送RR报文，根据接听客户端所发送的RR报文，发言客户端确认接听客户端的接收效果。应用本发明，不但实现了发言客户端迅速准确地确认接听客户端的接听效果，而且避免了由于很多用户抢占发言权而对系统造成的冲击。另外，发言用户可以向接收效果不好的接听客户端重新发送语音包。本发明能够满足具有较高可靠性要求的应用业务。同时，运营商还可以对此项服务进行计费，以增加其收入。
图1所示为PoC业务开展模式图；图2所示为实现PoC业务的流程图；图3所示为应用本发明一实施例的业务确认流程图。
具体实施例方式
为使本发明的技术方案更加清楚，下面结合附图及具体实施例再对本发明做进一步详细说明。
本发明的思路是由发言客户端在发送报告消息SR中设置要求接听客户端发送接收报告消息的标识信息；发言客户端在发言结束后请求PoC服务器将SR消息转发给接听客户端；接听客户端接收到PoC服务器转发的SR报文，根据该报文中的接收报告消息的标识信息判断出自身需要发送RR报文后，再向PoC服务器发送RR报文，根据接听客户端所发送的RR报文，发言客户端确认接听客户端的接收效果。
本发明使用实时传输协议(RTP)和实时传输控制协议(RTCP)作为语音流的传输和控制协议。下面先对RTP和RTCP做一简单介绍。
RTP协议是针对多媒体数据流的一种传输协议。该协议被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP协议本身并不能为按顺序传送的数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。
RTCP协议与RTP协议一起，提供流式媒体数据的拥塞控制和流量控制服务。RTCP包中含有已发送数据包的数量、丢失数据包的数量等统计资料，将RTP和RTCP配合使用，能得到有效的反馈和最小的开销，从而使传输效率最佳化，因而特别适合传送网上的实时数据。
RTCP协议中包括以下几种消息类型发送报告消息(SR)，该消息是活动的用户对发出业务流的统计，其报文结构如表1所示。其中，V表示版本(version)；P表示填充(padding)；RC表示接收报告计数(reception report count)；PT表示包类型(packet type)，用于指明RTCP类型，其中十进制的200代表SR；fraction lost表示丢失包数，即上一次SR或接收报告消息(RR)发送之后丢失的包数。表1边上的header表示报文头，sender info表示发送者信息，report block表示报告块。0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+header |V=2|P|RC | PT=SR=200 |长度(length) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 发送者的同步源标志(SSRC of sender)|+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+sender |网络时间戳(高位字节) (NTP timestamp，most significant word) |info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|网络时间戳(低位字节) (NTP timestamp，least significant word) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| RTP时戳(RTP timestamp) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 发送者的包数(sender’s packet count)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 发送者的字节数(sender’s octet count) |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+report | 第一同步源标志(SSRC_1(SSRC of first source))|block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+1| fraction lost |累计丢包数(cumulative number of packets lost) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 接收到的扩展的最高序列号 || (extended highest sequence number received) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 到达间隔抖动(interarrival jitter)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|上一SR报文时戳(last SR(LSR)) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 自上一SR的时间(delay since last SR(DLSR)) |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+report | 第二同步源标志(SSRC_2(SSRC of second source)) |block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+2: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| 特殊的扩展字段(profile-specific extensions) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+表1接收报告消息(RR)，该消息是不活动的用户对接收业务流的统计，其报文结构如表2所示。其中的英文缩写以及英文字段参见表1所示相应内容。0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+header |V=2|P|RC | PT=RR=201 | length|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| SSRC of packet sender |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+report | SSRC_1(SSRC of first source) |block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+1| fraction lost | cumulative number of packets lost |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| extended highest sequence number received |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| interarrival jitter |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| last SR(LSR) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| delay since last SR(DLSR) |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+report | SSRC_2(SSRC of second source) |block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+2: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| profile-specific extensions |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+表2源描述消息(SDES)，该消息用于标识用户，其报文结构如表3所示。其中Chunk表示块，其它的英文缩写以及英文字段参见表1所示相应内容。0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+header |V=2|P|SC | PT=SDES=202 | length|+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+chunk | SSRC/CSRC_1 |1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| SDES items || ... |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+chunk | SSRC/CSRC_2 |2+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| SDES items || ... |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+＝+表3图3所示为应用本发明一实施例的业务确认流程图。假设某个群组中有Client A、Client B、Client C和Client D四个用户，且Client A为发言客户端，其余为接听客户端。在本实施例中，使用RTP和RTCP作为语音流的传输和控制协议。
步骤301，Client A预先设置要求接收用户发送回执的标识RRflag，该标识位于SR报文的特殊的扩展字段(profile-specific extensions)字段中，该RRflag的格式如表4所示
表4在本实施例中规定RRflag＝1；f有四个取值，其具体取值含义如下00————不需接听客户端发送RR报文；01————需要部分接听客户端发送RR报文；10————需要全组所有的接听客户端均发送RR报文；11————无效；其余为保留字节；
如果要求组内所有接听客户端全部发送RR报文，则在SDES报文内SDES items字段的后续中不需要增加任何内容，如果要求组内部分接听客户端反馈RR报文，则在SDES报文内SDES items字段中提供需要反馈接听客户端的用户名，该用户名为用户加入群组时所登记的用户名；提供需要反馈接听客户端的用户名格式如表5所示
表5步骤302，Client A向PoC server申请发言；步骤303，PoC server完成对Client A的鉴权后，向用户A发送成功的响应消息(RSP)，允许用户A发言；步骤304，PoC server给所有的接听客户端发送系统占用的通知消息(OCCUPIED_IND)；步骤305，Client A向PoC server发送语音包，并由PoC server将ClientA所发送的语音包转发给Client B、C、D；同时，Client A记录本次发言所产生语音包的序号范围，即利用SR报文中的接收到的扩展的最高序列号(extended highest sequence number received)字段，记录本次发言所产生语音包的序号范围，extended highest sequence number received字段为32比特(bit)，每次发言都以上一次发言结束的包序号作为起始，等溢出后，再重新计数；步骤306，Client A发言结束后，释放发言请求(Floor)；步骤307，Client A发送SR报文给PoC server，要求获取接听客户端的反馈信息，该SR报文中包含Client A的标识信息；步骤308，PoC server将来自Client A的SR报文转发给所有的接听客户端；步骤309，Client B、C、D接收到来自PoC server的SR报文后，对该报文中的回执标识RRflag进行判断，并根据f的具体取值进行处理；
如果f的取值为00，则所有接听客户端不发送RR报文；如果f的取值为0l，则将SEDS中提供的需要反馈用户的用户名与自身的用户名相比较，如相同，则发送RR报文给PoC server，如不同，则不需要发送RR报文；如果f的取值为10，则所有接听客户端全部发送RR报文给PoC server；如果f的取值为11，则该标识无效，所有接听客户端不发送RR报文；在本实施例中，假设预先设置f的值为01，且SEDS中提供的用户名为Client B和Client C，即只有Client B和Client C发送RR报文，且所发送的RR报文中包含自身的标识；步骤310，PoC server接收到来自Client B、C的RR报文后，为了节约带宽，首先进行缓存，然后再按照RTCP的定义，将所收集到的RR报文组装成一个RR报文后，发送给Client A；上述缓存方式为预先设定一段等待的时间，如5秒，则PoC server每5秒向Client A发送一次按照RTCP定义已组装好的RR报文；或者，上述缓存方式为预先设定从接听客户端收集到的RR报文的个数，如31个，则PoCserver每收集到31个来自接听客户端的RR报文后，向Client A发送一次按照RTCP定义已组装好的RR报文；步骤311，Client A接收到来自PoC server的RR报文后，首先根据RR报文中的extended highest sequence number received字段判断该RR报文是否属于本次发言所产生的语音包的序号范围之内，如果不是，则不做任何处理，如果是，则根据RR报文中的接收总包数、到达间隔抖动等参数计算出本次发言中各个发送RR报文的接听客户端的丢包率以及抖动时间，并由此确认该各个接听客户端的接收效果。
当某个或某几个接听客户端的接收效果较差时，Client A可以采用闪烁光标等方式提示用户A给接收质量较差的客户端重新发送语音包。
在上述实施方式中，接听客户端的接听质量是由发言客户端根据来自接听客户端的RR报文统计出的。当然，该统计操作也可以由PoC服务器来完成，即由PoC服务器根据来自接听客户端的RR报文统计接听客户端的接听质量，然后将其转换为已设定好的接收质量等级信息，将该接收质量等级信息直接发送给发言客户端。
例如，设定丢包率小于10％，抖动小于1s时接收质量优良；丢包率小于20％，抖动小于2s时接收质量为可接收；丢包率小于30％，抖动小于3s时接收质量较差；丢包率大于30％，抖动大于3秒时接收质量差。PoC服务器计算出各个发送RR报文的接听客户端的丢包率和抖动时间后，将其转换为相应的接收质量等级，然后直接给发言客户端发送各个接听客户端的接收质量等级信息，发言客户端由此确认各个接听客户端的接收效果。这样，可以简化对客户端的要求。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
权利要求
1.一种实现确认PoC业务接收效果的方法，其特征在于，该方法包括以下步骤a、发言客户端在发送报告消息SR中设置要求接听客户端发送接收报告消息的标识信息；b、发言客户端在发言结束后请求PoC服务器将SR消息转发给接听客户端；c、接听客户端接收到PoC服务器转发的SR报文后，根据该消息中的接收报告消息的标识信息判断自身是否需要发送RR报文，如果是，则向PoC服务器发送RR报文后，执行步骤d，否则不做任何处理；d、根据接听客户端所发送的RR报文，发言客户端确认接听客户端的接收效果。
2.根据权利要求1所述的方法，其特征在于，步骤c所述接听客户端判断自身是否需要发送RR报文的方法包括以下步骤c1、根据SR报文中的接收报告消息的标识信息判断是否要求所有的接听客户端发送RR报文，如果是，则向PoC服务器发送RR报文，否则执行步骤c2；c2、判断是否要求部分接听客户端发送RR报文，如果不是，则不需要自身发送RR报文，如果是，则进一步判断需要发送RR报文的用户名中是否包含自身的用户名，如果是，则向PoC服务器发送RR报文，否则不需要自身发送RR报文。
3.根据权利要求1所述的方法，其特征在于，步骤d所述根据接听客户端所发送的RR报文，发言客户端确认接听客户端接收效果的方法是发言客户端接收到PoC服务器转发的RR报文后，首先判断所接收到的报文是否属于本次发言的语音包，如果是，再根据接收到的RR报文计算出丢包率和到达间隔抖动时间确认各个发送RR报文的接听客户端的接收效果。
4.根据权利要求3所述的方法，其特征在于，所述PoC服务器给发言客户端转发RR报文的方法是PoC服务器接收到来自接听客户端的RR报文后，首先进行缓存，然后再按照RTCP协议的定义，将所收集到的RR报文组装成一个RR报文后，发送给发言客户端。
5.根据权利要求4所述的方法，其特征在于，所述缓存的方式为PoC服务器每隔一段已设定的时间发送一次已组装的RR报文，或者，每收集到已设定个数的RR报文，发送一次已组装的RR报文。
6.根据权利要求3所述的方法，其特征在于，所述发言客户端判断所接收到的报文是否属于本次发言的语音包的方法是根据RR报文中的接收到的扩展的最高序列号extended highest sequence number received字段判断该RR报文是否属于本次发言所产生的语音包的序号范围之内，如果是，则属于本次发言所产生的语音包，否则，不属于本次发言所产生的语音包。
7.根据权利要求1所述的方法，其特征在于，步骤d所述根据接听客户端所发送的RR报文，发言客户端确认接听客户端的接收效果的方法是由PoC服务器根据来自接听客户端的RR报文计算出各个发送RR报文的接听客户端的丢包率和到达间隔抖动时间，并将已计算出的丢包率和到达间隔抖动时间转换为接收质量等级发送给发言客户端，由发言客户端根据该接收质量等级确认各个发送RR报文的接听客户端的接收效果。
8.根据权利要求1所述的方法，其特征在于，该方法进一步包括发言客户端提示发言用户向接收效果较差的接听客户端重新发送语音包。
全文摘要
本发明提供了一种实现确认PoC业务接收效果的方法，其关键是由发言客户端在SR中设置要求接听客户端发送接收报告消息的标识信息，发言客户端在发言结束后请求PoC服务器将SR消息转发给接听客户端；接听客户端接收到PoC服务器转发的SR报文，根据该报文中的接收报告消息的标识信息判断出自身需要发送RR报文后，再向PoC服务器发送RR报文，根据接听客户端所发送的RR报文，发言客户端确认接听客户端的接收效果。应用本发明实现了发言客户端迅速准确地确认接听客户端的接听效果，而且避免了由于很多用户抢占发言权而对系统造成的冲击。本发明能够满足具有较高可靠性要求的应用业务。同时运营商还可以对此项服务进行计费，以增加其收入。
文档编号H04W4/10GK1728839SQ200410054669
公开日2006年2月1日 申请日期2004年7月27日 优先权日2004年7月27日
发明者罗龙 申请人:华为技术有限公司