CN100359965C - 一种实现确认PoC业务接收效果的方法 - Google Patents

一种实现确认PoC业务接收效果的方法 Download PDF

Info

Publication number
CN100359965C
CN100359965C CNB2004100546695A CN200410054669A CN100359965C CN 100359965 C CN100359965 C CN 100359965C CN B2004100546695 A CNB2004100546695 A CN B2004100546695A CN 200410054669 A CN200410054669 A CN 200410054669A CN 100359965 C CN100359965 C CN 100359965C
Authority
CN
China
Prior art keywords
message
client
speech
reception
poc 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.)
Expired - Fee Related
Application number
CNB2004100546695A
Other languages
English (en)
Other versions
CN1728839A (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.)
Huawei Technologies 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 CNB2004100546695A priority Critical patent/CN100359965C/zh
Publication of CN1728839A publication Critical patent/CN1728839A/zh
Application granted granted Critical
Publication of CN100359965C publication Critical patent/CN100359965C/zh
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Mobile Radio Communication Systems (AREA)

Abstract

本发明提供了一种实现确认PoC业务接收效果的方法，其关键是由发言客户端在SR中设置要求接听客户端发送接收报告消息的标识信息，发言客户端在发言结束后请求PoC服务器将SR消息转发给接听客户端；接听客户端接收到PoC服务器转发的SR报文，根据该报文中的接收报告消息的标识信息判断出自身需要发送RR报文后，再向PoC服务器发送RR报文，根据接听客户端所发送的RR报文中的参数，发言客户端确认接听客户端的接收效果。应用本发明实现了发言客户端迅速准确地确认接听客户端的接听效果，而且避免了由于很多用户抢占发言权而对系统造成的冲击，能够满足具有较高可靠性要求的应用业务。同时运营商还可以对此项服务进行计费，以增加其收入。

Description

一种实现确认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                   3
        0 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                   3
        0 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                   3
         0 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所示：
  0   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
  RRflag＝1     f                                                          保留
表4
在本实施例中规定RRflag＝1；f有四个取值，其具体取值含义如下：
00----不需接听客户端发送RR报文；
01----需要部分接听客户端发送RR报文；
10----需要全组所有的接听客户端均发送RR报文；
11----无效；
其余为保留字节；
如果要求组内所有接听客户端全部发送RR报文，则在SDES报文内SDES items字段的后续中不需要增加任何内容，如果要求组内部分接听客户端反馈RR报文，则在SDES报文内SDES items字段中提供需要反馈接听客户端的用户名，该用户名为用户加入群组时所登记的用户名；提供需要反馈接听客户端的用户名格式如表5所示：
0  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
    RNAME＝2                    长度                         用户加入群组的用户名
表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报文后，对该报文中的回执标识RRnag进行判断，并根据f的具体取值进行处理；
如果f的取值为00，则所有接听客户端不发送RR报文；
如果f的取值为01，则将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报文的接听客户端的丢包率和抖动时间后，将其转换为相应的接收质量等级，然后直接给发言客户端发送各个接听客户端的接收质量等级信息，发言客户端由此确认各个接听客户端的接收效果。这样，可以简化对客户端的要求。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

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所述的方法，其特征在于，该方法进一步包括：发言客户端提示发言用户向接收效果较差的接听客户端重新发送语音包。
CNB2004100546695A 2004-07-27 2004-07-27 一种实现确认PoC业务接收效果的方法 Expired - Fee Related CN100359965C (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CNB2004100546695A CN100359965C (zh) 2004-07-27 2004-07-27 一种实现确认PoC业务接收效果的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CNB2004100546695A CN100359965C (zh) 2004-07-27 2004-07-27 一种实现确认PoC业务接收效果的方法

Publications (2)

Publication Number Publication Date
CN1728839A CN1728839A (zh) 2006-02-01
CN100359965C true CN100359965C (zh) 2008-01-02

Family

ID=35927789

Family Applications (1)

Application Number Title Priority Date Filing Date
CNB2004100546695A Expired - Fee Related CN100359965C (zh) 2004-07-27 2004-07-27 一种实现确认PoC业务接收效果的方法

Country Status (1)

Country Link
CN (1) CN100359965C (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0540081A1 (fr) * 1991-10-23 1993-05-05 Trt Telecommunications Radioelectriques Et Telephoniques Système de transmission d'information selon un multiplex temporel
US5457735A (en) * 1994-02-01 1995-10-10 Motorola, Inc. Method and apparatus for queuing radio telephone service requests
WO1997028658A2 (en) * 1996-02-01 1997-08-07 Qualcomm Incorporated Method and apparatus for providing a private communication system in a public switched telephone network
US5835485A (en) * 1995-11-22 1998-11-10 Motorola, Inc. Method for dynamic routing of communication messages
WO1999009768A1 (en) * 1997-08-18 1999-02-25 Qualcomm Incorporated Vehicle communication system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0540081A1 (fr) * 1991-10-23 1993-05-05 Trt Telecommunications Radioelectriques Et Telephoniques Système de transmission d'information selon un multiplex temporel
US5457735A (en) * 1994-02-01 1995-10-10 Motorola, Inc. Method and apparatus for queuing radio telephone service requests
US5835485A (en) * 1995-11-22 1998-11-10 Motorola, Inc. Method for dynamic routing of communication messages
WO1997028658A2 (en) * 1996-02-01 1997-08-07 Qualcomm Incorporated Method and apparatus for providing a private communication system in a public switched telephone network
WO1999009768A1 (en) * 1997-08-18 1999-02-25 Qualcomm Incorporated Vehicle communication system

Also Published As

Publication number Publication date
CN1728839A (zh) 2006-02-01

Similar Documents

Publication Publication Date Title
EP1510090B1 (en) Method for controlling parties in real-time data group communication using acknowledgement packets
US7428422B2 (en) Method and system for setting application settings for a push-to-talk service
US7991419B2 (en) Press-talk server, transcoder, and communication system
US7561892B2 (en) PT service system and method
US7058042B2 (en) One-to-one communication
US7929475B2 (en) System and method for multicast communications using real time transport protocol (RTP)
JP4575663B2 (ja) Ｕｍｔｓネットワークにおいてマルチキャスト通信を実行するための方法および装置
KR100951026B1 (ko) 무선 원격통신 장치들 간의 그룹 통신들에 있어서 ｖｏｉｐ데이터 패킷들을 분배하기 위한 시스템 및 방법
KR100810222B1 (ko) 셀룰러 기반의 푸쉬 투 토크에서 전 이중 통화 제공 방법및 시스템
US8803942B2 (en) Session processing method and system
CN101238741B (zh) 用于广播即按即说群会话的方法和设备
US7573837B1 (en) Establishment of multicast Push-to-X over Cellular (PoC) communication
CN1774947A (zh) 管理通信会话的方法
US7873379B2 (en) Conference communication system and method with notification
KR100716817B1 (ko) 이동 통신 단말기 호 셋업 방법
JP4856251B2 (ja) 無線通信ネットワークにおけるヘッダの抑制
EP1380182B1 (en) One-to-one communication in a system having different control plane and user plane logical entities
WO2009071005A1 (fr) Procédé, système, serveur et client pour la transmission de données multimédia diffusées en continu
CN100417245C (zh) 基于VoIP技术的“一键通”业务实现系统及方法
CN100438656C (zh) 一种实现集群业务的系统和方法
CN100359965C (zh) 一种实现确认PoC业务接收效果的方法
CN100542338C (zh) 码分多址数字集群系统中语音传输及呼叫信令交互方法
KR20030033158A (ko) 이동통신 망에서의 ｉｐ 멀티캐스트 패킷 전송을 위한어플리케이션 구현방법
CN1852382A (zh) 基于蜂窝网络的一键通业务语音流的计费方法及其系统
KR100612674B1 (ko) 이동통신 시스템에서 양방향 멀티미디어 콘텐츠 서비스제공 방법

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
C17 Cessation of patent right
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20080102

Termination date: 20130727