基于蜂窝网络的按键通话

PoC（基于蜂窝网络的按键通话）提供了直接的一对一和一对多的语音通信服务。其基本思想很简单。用户选择要讲话的人或群组，按下对讲键后开始讲话，会话是实时连接的。按键通话会话是单向通信：当一个人说话时，其他人只能听。说话的顺序是通过按下对讲键来请求的，基于先来先服务的方式进行授权。按键通话的言语连接通常不需要接收者的应答，可通过电话内置的扬声器传给接收者；或是另一种方式：用户只有在接受邀请后才会选择接收按键通话会话。如果需要更多的私密性，他们还可以通过耳机听取会话。

按键通话服务基于多重单播（multi-unicasting）技术。每个发送客户端向指定的按键通话应用服务器发送分组数据业务流量，如果是群组会话，服务器将生成的业务流量副本发往所有的接收者（见图6-1）。在接入网或核心网都没有应用组播技术，无线网络实施的是移动性管理。因为这个原因，按键通话方案能够透明地运行于蜂窝网络和固定网络中。PoC会话控制和其他信号传输是基于SIP,语音流量传输是利用基于RTP/RTCP（实时传输协议/实时传输控制协议）的流承载方式。

图6-1基于蜂窝网络的按键通话

与电路交换服务相比，PoC利用蜂窝式接入和无线资源的效率更高。只在讲话的突发时间片内保留单向网络资源，而不是在整个会话期间保留双向资源。图6-2展示了一个例子。与传统的双向无线解决方案相比，如LMR（陆地移动无线）方案和PMR（行业移动无线）方案以及FMR（家庭移动无线）方案等，PoC因为利用了GSM/WCDMA/CDMA网络而提供了更好的覆盖能力。PoC使得两个人或在一组群内能够在全国或跨区域（GPRS/EDGE/WCDMA/CDMA2000）范围内进行按键通话。

图6.2语音呼叫与基于蜂窝网络的按键通话对比

6.1 POC体系架构

OMA（开放移动联盟）PoC标准Release1的体系架构，构建于PoC客户端、PoC应用服务器、PoCXML文档管理服务器（XDMS）之上。可以把XDMS看作是一种应用配置设置管理服务器，因为它保存了特定应用的配置设置。存储了PoC特定数据的XDMS就称为“PoCXDMS”。利用参考点PoC-8（见图6-3）,PoC服务器能够获取与PoC相关的文档（如访问列表）；利用参考点PoC-5（见图6-3）,PoC服务器能够从共享的XDMS中获取通用列表（如myfriends@example.com列表中的成员）。PoC服务器处理特定应用的任务，如通话突发时间片控制（为某个用户保留通话突发时间片）和PoC会话控制。它们还为运营商提供了配置和网管系统的接口，创建特定应用的CDR（计费细节记录）话单。PoC服务器通过IMS服务控制参考点接入IMS网。IMS处理通用的功能，如PoC用户认证、会话路由和基于SIP的通用计费。通常PoC客户端是UE（用户设备）中的软件，但也可能是应用程序（可能在PC中）。

通常，在线状态服务总是与PoC相关，因为在线状态服务为PoC提供了增值功能（例如，用户能够知道另一个用户是否愿意以及是否可以进行PoC通信）。即使PoC服务的运行不需要在线状态，仍然可以将其表示在体系架构图中（见图6-3）。

6.1.1PoC服务器

PoC服务器是IMS体系架构中的应用服务器，为用户提供PoC服务。它控制PoC会话建立过程，执行为PoC群组会话定义的策略（例如：允许谁加入；允许谁邀请更多的成员；当某个特定用户离开时，决定是否要释放会话；当某个特定用户加入时，决定是否要邀请其他用户），提供用户群组的信息（例如通知某人何时加入群组或何时离开群组）。不仅如此，必要时PoC服务器还处理媒介分配和适配。而且，它还充当通话突发控制点的功能，即PoC服务器决定谁有权发送媒体,通知其他用户发送媒体的权限已经赋予了某人等等。这个机制称为“通话突发控制”（6.3.2节将详细介绍）。于是，简言之，PoC服务器同时处理与PoC服务有关的控制面和用户面的业务流量，为此它使用了IMS的参考点ISC和Mb。

图6-3基于蜂窝网络的按键通话体系架构

OMA定义了两种不同的PoC服务器角色，参与PoC功能和主控PoC功能。在PoC会话建立过程中，指派PoC服务器角色，用这种方式，只有一个PoC服务器执行PoC控制功能，两个或两个以上的PoC服务器执行参与PoC功能，具体数目取决于参与其中的PoC会话的数量。在一对一PoC会话和专用PoC群组会话的情况下，实施邀请用户的那个PoC服务器将执行控制PoC功能。在聊天PoC群组或预先安排的群组会话的情况下，拥有或驻留群组标识的那个PoC服务器实施控制PoC功能[OMAPoCAD]。

从PoC客户端发出的SIP信令总是首先到达参与PoC功能，它继续将SIP信令流量进一步转发到主控PoC功能。与此相反，PoC客户端可以有直接通往主控PoC功能的媒体和媒体信令连接。图6-4说明了体系架构，表6-1总结了PoC服务器不同功能的分布。

6.1.2  PoC客户端

根据OMA标准，PoC客户端是UE上即功能实体，能够使用PoC特性标签将自己注册到IMS中，在SIPREGISTER请亲中指示PoC释放版本，初始化/修改/释放PoC会话，支持用户面过程（例如：从/向PoC服务器接收/发送通话突发，支持通话突发控制机制，用户面适配），支持PoC服务设置和接收即时人员告警。

图6-4  POC服务器体系架构

表6-1 PoC服务器功能分布

6.2PoC特性

6.2.1PoC通信

PoC支持各种类型的通信模式，以满足不同的群组通信需求。这些模式的主要差别在于群组策略和会话建立。换言之，用户如何创建一个组并添加/删除组员？他们如何激活一个群组会话，如何管理访问控制？在拨出群组通信中，用户邀请一组用户加入群组会话。被邀用户接收加入会话的指示，他们可以通过自动应答或手工应答来加入。被邀的群组可以是预定义PoC群组，或临时从主叫用户电话簿中选择的一系列用户（称为临时PoC群组）。在后一种情况下，特别是在进行拨出会话之前如果能够看到其他用户可达性或在线状态，显然能为该用户带来额外收益。拨出会话适合于无事先计划的情况，或必须仔细选择参与方的情况。

预定义PoC群组有一些特殊规则（OMA规定）。第一，同一个预定义PoC群组中，当任何一个组员要求其他组员加入时，就建立了组员之间的PoC会话。第二，在预定组的第一个组员接受了邀请、主控PoC服务器将媒体使用权授予预定组的发起人时，通信即开始了。第三，只有预先定义的成员（即预定义组的成员）才允许加入预定义组［OMAPoCRD］。类似的，临时PoC群组也有一些规则。当分一个PoC用户邀请一个或多个用户加入PoC会话时（注：一对一PoC会话就是有两个参与人的临时PoC会话），就创建了临时PoC组。只有那些已受邀加入临时PoC会话的用户被允许——即，用户必须先从临时组中的一个当前成员处收到加入临时组的请求（如从主控PoC服务器收到SIPINVITE或SIPREFER）=主控PoC服务器的本地策略可能只允许临时PoC组的发起人加入更多的用户（出于计费目的）［OMA PoC RD］。

在参加组通信即聊天组过程中，参与者本身需明确的加入PoC群组会话进行通信。这样一来，用户能够完全控制他们想要加入哪一个组。除非已经加入到组中，否则他们永远不会收到任何流量。加入操作非常适合在例行的或预先计划的行为中进行通信。参加聊天PoC组与现实生活中的行为很类似，如看电视、看电影或参加会议。聊天PoC会话可以持续数小时，而实际的通信只占总的会话时间的一小部分。因此，处于聊天PoC会话的状态下，不应该阻止用户同时接收其他会话。用户应该也能够同时加入好几个聊天会话（如：“我的家庭”、“篮球球友”、“啤酒酒友”），这就要求系统能够支持并发会话。

聊天组可以是无限制组，没有访问控制，不限制组员名单。无限制组对任何人开放，只要他知道组标识（组的SIPURI）。组标识可以很容易地找到，例如在运营商门户网站上或聊天室内。无限制PoC聊天组适合于讨论通用或特定话题的公开论坛（如钓鱼、汽车、足球）；受限组的访问只限定于预定义的用户。对于使用了访问控制方法的受限组，参见6.2.4节。为了加入一个受限组，用户需要知道组标识（组SIP URI）,而且他们要有权加入组会话。受限PoC聊天组最适合商务用户的需要，这些用户在日常工作中需要在安全的组内进行持续通信。图6-5总结了不同的PoC通信模型。

图6.5  不同的PoC通信模型

6.2.2 并发PoC会话

与传统的电话服务相比，PoC提供了同时参加一个以上PoC会话的能力，并不会挂起任何一个会话。这种能力称为“并发PoC会话功能”。例如，用户Alice在其PoC设备上拥有如下能力：当设备开机时，能自动加入Alice预先配置好的组。我们假设Alice激活了如下三个组：“我的家庭”、“工作同事”和“篮球队”。加入这些组以后，Alice能够从任何一个组发送和接收媒体流。这种功能比单一会话模式有个明显的优势：Alice不需要猜测在某一时刻哪个组是活跃的。不仅如此,这种模式还允许用户挂起聊天组，但还能接收与其他用户的一对一PoC会话。

当Alice想要说话时，她只需要选择恰当的群组再按下PoC按键。从网络接收媒体有些挑战性，因为这需要Alice的PoC服务器的支持。如果当Alice同时参与了多个PoC会话时，有一个以上的会话呼入媒体，PoC服务器需要过滤呼入的PoC业务流量。参与PoC功能过滤了业务流量，以便Alice只听到一个谈话。业务流量过滤遵循如下规则（按优先顺序）：

•  用户可以将自己锁定在一个群组中。只有该群组的业务流量可以传递给用户（类似于电话服务）。

•  用户可以设置某一个会话为首要PoC会话。首要会话的业务流量总是可以传递给用户（如果当前该用户不是正在次要PoC会话中讲话），尽管一个次要PoC会话中正好也有业务流量。

•  在次要PoC会话中，只要当前谈话保持激活状态，就始终传递当前对话谈话的业务流量。在沉默期后（时间长取决于运营商），PoC服务器从其他会话中选择一个激活的媒体。

例子中用户Alice选择"我的家庭”为首要PoC组，其余组自动归类为次要组。现在无论何时只要她的家庭成员说话，她就能听见他们说的内容。为了将“我的家庭”组设置为首要会话，她的设备需要在特定属性中设置值为“1”，即在会话请求（SIPINVITE,UPDATE或RE-INVITE）的SDP有效负荷中a=poc_sesspriority="1/0”。为了变化优先级的值，可以使用“0”，或者设备能够向其祐组指示优先级"1”，然后就可认定PoC服务器交换了优先级。

当Alice想要集中精力到单一群组通信时,她的设备需要在特定属性中设置值为“1”，即在会话请求（SIPINVITE,UPDATE或RE-INVITE）的SDP有效负荷中a=poc_lock="l/0”。为解除会话锁定，她的设备需要指派锁定到其他会话上，或者发出另一个会话请求并指示值为“0”[OMAPoCControlPlane]。

6.2.3 PoC会话建立模式

本节将介绍不同会话的建立模式。建议读者在阅读本节之前，先阅读PoC通信的章节（参见6.1.1节）。

存在两种不同的会话模式：按需会话和预建立会话。两类会话模式的主要区分别在于媒体参数协商。在预建立会话模式中，用户在向其他PoC用户发出PoC会话请求之前，就与其参与PoC功能建立一个会话，并且会先协商所有媒体参数。在按需会话中采用了“通常的”SIP方法一即当用户请求PoC会话时，才协商名媒体参数。预建立会话模式允许PoC客户端邀请其他PoC客户端，或者接受PoC会话而无需再协商媒体参数，这将额外节约会话建立时间。图6-6展示了预建立会话用法的简化示例。

在图6-6的上半部分,PoC客户端建立了预建立会话。在图的下半部分,Tobias想要联系用户Tuomo。Tobias的PoC客户端发出SIP REFER请求，其中包含了目标用户Tuomo的标识。Tobias的PoC服务器将承担主控PoC功能及参与PoC功能，并通过IMS向目的网络发送SIPINVITE请求。Tuomo的PoC服务器（参与）收到SIPINVITE请求并立即接受该会话，由于Tuomo使用了预建立会话并设置他的应答方式为自动应答。Tuomo的PoC客户端从他的PoC服务器（参与）接收到通话突发控制消息。通话突发消息指示Tobias发出呼叫，Tuomo的PoC客户端应答了这个消息。当主控PoC功能得到200OK消息时，它向Tobias发出一个通话突发控制消息，指示已经授予了讲话的许可。类似的，主控PoC功能向Tuomo的PoC客户端发出通话突发控制消息，指示发送媒体数据的许可已经授予了Tobiaso

图6.6 预建立PoC会话的建立

图6-7 在目的方网络使用Unconfirmed模式建立按需PoC会话

图6-7展示了采用按需PoC会话建立PoC会话的过程。当Tobias想要建立与Tuomo的PoC会话时，他的设备生成SIP INVITE请求，包括设备的媒体能力和媒体传输信息。Tobias的PoC服务器将承担主控PoC功能及参与PoC功能，通过IMS向目的网络发送SIPINVITE请求。Tuomo的PoC服务器（参与）接到SIPINVITE请求，获知Tuomo的应答模式设置。此时，Tuomo早已经指示为自动应答模式，所以他的PoC服务器向主控PoC服务器返回183SessionProgressSIP回应。这个回应包含Tuomo使用自动应答模式的信息。与此同时，Tuomo的PoC服务器发出一个SIPINVITE请求给Tuomo的设备。接到INVITE请求以后，Tuomo的设备自动应答200 OKSIP消息。当Tuomo的PoC服务器接到200 OK应答后，它向呼叫发起网络发出200 OK应答。在接到183 Session Progress的同时，主控PoC功能向发起人（Tobias）发出200OK响应。主控PoC功能收到183 Session Progress响应以后，如果愿意缓存媒体流，就可能授权发起方用户（Tobias）讲话（图6-7中通话突发控制消息）。缓存是需要的，因为在收到接收方参与PoC功能的200 OKSIP最终响应之前，不允许主控PoC功能转发媒体流给接收方参与PoC功能。如果主控PoC功能不愿意缓存媒体，在收到200OKSIP响应以后，它就授权发起方用户可以讲话。

除了上述两个案例以外，还有许多不同的组合，因为发起方用户可能使用按需模式也可能使用预建立模式；类似的，目的方用户可以使用按需模式，也可以使用预建立模式。此外，主叫用户可以申请被叫用户PoC设备自动应答呼入会话——即被叫PoC用户设备可立即听见邀请方PoC用户的话音，无需被叫PoC用户进行任何动作。这个特性称为“手动应答覆盖特性”。手动应答覆盖的授权发生在目的方用户的网络中——即，如果想允许某些人使用手工应答覆盖，就必须设置恰当的授权规则。在本书撰稿时，关于用户如何请求手工应答覆盖的细节还在讨论之中。

不仅如此，目的方用户可以使用手工应答模式或自动应答模式。表6-2展示了可能的PoC会话组合。

表6-2  各种POC会话建立组合小结

6.2.4 呼入PoC会话处理

本章开头提到按键通话通常不需要接收方应答即可连接，通过PoC设备的内置扬声器播放。这种情况发生时，用户把他的终端设备设置成自动应答模式，主叫方包含在用户的访问控制列表中，而且主叫方在访问控制列表中设置了特定的值。本节论述其运行过程，以及处理呼入PoC会话的其他机制。

让我们从应答模式入手，定义了两种不同的应答模式：自动应答模式和手工应答模式。当使用自动应答模式时，PoC设备接受呼入PoC会话后，无需等用户做出任何动作，即能够立即播放呼入媒体流。手工应答模式是常规模式，用户需要接受呼入PoC会话请求，然后PoC设备才能向PoC服务器确认接受了呼入的PoC会话。应答模式也会向PoC服务器传递信令来执行主控PoC功能，进而使用SIP响应中的Unconfirmed㊀或Confirmed0指示反馈给发起方用户功能。当目的方PoC设备采用手工应答模式，并且已经发出SIP200 OK响应表示接受了新的PoC会话时，就会给出Confirmed指示。除此以外，目的方参与PoC服务器功能时就会产生Unconfirmed指示。6.4节描述了PoC客户端如何通知PoC服务器它期望的应答模式。

当能够确定主叫用户行为得当——即主叫用户不会不恰当说话并且在用户可达的情况下，使用自动应答模式将是非常好而且有用的功能。然而，用户不能确定谁会发出呼叫，因此如果对所有可能的用户都使用自动应答模式，他们会感觉不舒服。另一方面，始终使用手工应答模式又会觉得不方便。不仅如此，用户可能想自动拒绝来自某些用户或PoC组群的PoC会话。

为了克服这些类的问题，开发了访问控制机制。访问控制意味着用户能够：

•  选择性地允许或阻止来自其他PoC用户和PoC群组的呼入PoC会话；

•  选择性地定义能够自动接受哪些用户的PoC会话。

承担参与PoC功能的PoC服务器对被叫PoC用户执行访问控制。为了执行访问控制，PoC用户需要创建访问控制列表文档并发到PoCXDMS«整个过程的更黑详细内容参见8.6节。此外，如果PoC用户激活了呼入PoC会话阻塞，就能够阻分止所有的呼入PoC会话（这个过程将在6.2.7节描述）。

可以通过一个简单例子来描述在PoC服务器和PoC客户端使用应答模式和访问控制列表的结果。Tobias已经买了支持PoC功能的设备，因为他的大多数朋友务都在使用它。Tobias的设备已开机，并注册到IMS上。首先，Tobias打开一个窗口，为他的伙伴建立访问控制列表。他决定把Theresa、Tuomo和Matias作为最亲密的朋友，因此把他们的标识放在访问控制列表中的"接受”类。同时，他把John的标识加入“拒绝”类，因为他不想从他那里接收任何会话。完成了访问控制列表以后，Tobias接受该列表，他的设备会将该列表文档上传到PoCXDMS。其次,Tobias选择设置自己的应答模式为自动应答模式。通过Tobias的设备这个信息就发送到Tobias的PoC服务器上。现在所有的必要设置都已完成，Tobias就可以利用这些设定了。

过了一会（可能是在发送了一个即时个人警示以后），Tuomo企图联系Tobias。一个一对一PoC会话请求从Tuomo设备发出，发往Tobias的设备，当请求到达Tobias的PoC服务器时，PoC服务器将从PoCXDMS提取访问控制列表，发现

©Unconfirmed指示是PoC服务器反馈的指示，用以确认：能够接收媒体，并且PoC客户端能够接收媒体;在PoC服务器发送Unconfirmed指示之后，再确定是否所有外出元素都已就绪或甚至是能够接收媒体。

©Confirmed指示是PoC服务器反馈的信令消息，用以确认：PoC服务器、PoC服务器和目的方PoC客户端之间的所有的其他中介网元，都能够并且愿意接收媒体[OMAPoCControlPlane].

Tuomo在访问控制列表的"接受"类中，并且Tobias已经指示愿意自动接受呼入PoC会话；因此，PoC服务器决定放行PoC会话。当PoC服务器向Tobias的PoC设备发出呼入PoC会话请求时，在请求中包括了自动应答指示。根据自动应答指示，Tobias的电话接受了PoC会话，激活了扬声器，等待呼入PoC话音流。

这天晚些时候，Tobias的朋友Maija（她已经订购了Tobias的在线状态信息），发现了Tobias在线状态信息显示可用PoC业务。意识到这点以后，Maija试图联系Tobias。当PoC会话请求到达Tobias的PoC服务器时，这次PoC服务器在访问控制列表中没有发现Maija。然而，Tuomo已经指示愿意自动接受呼入PoC会话,于是PoC服务器决定接受呼入PoC会话，但是与前例不同，它会在请求中加入手工应答指示。根据手工应答指示，Tobias的电话将不会马上接受PoC会话；相反它会提示Tobias并显示主叫是Maija。

当John试图联系Tubias时，PoC服务器将发现John在“拒绝”类中，就自动拒绝来自John的呼入PoC会话，使PoC会话请求根本不会到达Tobias的设备。

图6-8展示了使用访问控制列表和应答模式㊀后的呼入会话处理过程。

图6-8呼入PoC会话处理决策书，说明了访问控制列表和用户应答模式的影响

6.2.5 即时个人警示

有时主叫用户无法联系接收方（例如用户激活了呼入会话阻塞），于是主叫方可能希望留个明确的消息，请被叫方回呼。这个消息叫作“即时个人警示”。当期望使用不那么明显的警示方法时，即时个人警示请求可以用于替代按键通话的话音传输。

㊀如果请求了手工应答覆盖，并且允许主叫用户用这个特性，那么就会执行自动应答模式。如果请求不被获准，那么应答模式的选择就遵从图6-8。

任何时候用户想要向其他用户发出即时个人警示请求时，用户选择目标（如从电话簿），发出即时个人警示。为此，要使用SIP MESSAGE 方法。从接收者看来，需要区分常规的SIP即时个人警示和PoC即时个人警示，因为它们都使用了SIP消息方法。区分出PoC即时个人警示使得PoC客户端能够创建自动操作。为此，要求发起方PoC客户端必须在Accept Contact头字段包含PoC特性标签，

"+g.poc.talkburst"、“require”和"explicit"参数：

MESSAGE sip：bob@example.comSIP/2.0

From：<sip：tobias@home1.fr>；tag=31415

To：<sip：bob@example.com>

Acept-Contact：*；+g.poc.talkburst；require；explicit

User-Agent：poc-client/OMA1.0

如果用户不想接收即时个人警示，他可以激活Incoming InstantPersonal AlertBarringo当激活这个服务是，为此用户服务的参与PoC服务器必须阻止传递，并向发送方反馈SIP 480 Temporarily Unavailable错误响应[OMA PoC ControlPlane]。

6.2.6群组公告

当PoC用户Tobias计划去芬兰度暑假时，他决定与姐姐Theresa、芬兰朋友Tuomo和Matias创建一个聊天PoC组。在创建了群组summervacation@poc.example.com以后，他决定将创建的组公告给Theresa、Tuomo和Matias0为此，Tobias发送一个群组公告，其中包括了创建组的所有必要信息：组名称（URI和显示名字）、组类型、公告文本。当其他族成员接到组公告时，他们可以决定保存联系信息以便日后通信。使用接收到的信息时，他们能立即决定拨叫那个组。

一个群组公告可以利用SIP MESSAGE发给一个或多个用户，或者可以一次发给所有的组成员，消息正文中包含了PoC特定内容，是MIME（多用途因特网邮件扩展）vnd.poc.advertisement+xml类型。此外，发送方必须包含Accept-Contact头字段并填入PoC特性标签"+g.poc.groupad”,且带上“require”和“explicit”参数。使用特性标签和上述参数，能够保证公告只传递给能够理解群组公告消息的支持PoC的UE。

例子中由Tobias的PoC设备发出的群组公告形式如下：

MESSAGE:sip:summervacation@poc.homel.fiSIP/2.0

From:<sip:tobias@home1.fr>;tag=31415

To:<sip:summervacation@poc.home1.fr>

Accept-Contact:*;+g.poc.groupad;require;explicit

User-Agent:PoC-Client/OMAl.0

Content-Tyoe:application/vnd.poc.group-advertisement+xml

Content-Length:(482)

<?xmlversion=n1.0nencoding=HUTF-8H?>

<group-advertisement

        xmlns=Hum:oma:params:xml:ns:poc:group-advertisemenf*

        xmlns:xsi=nhttp://www.w3.org/2001/XMLSchema-instance"

        xsi:schemaLocation="um:oma:params:xml:ns:poc:group-advertisementn>

 <note>Tobiassummervacationplanning</note>

 <grouptype=‘’dialed-in”>

      <display-name>GreattriptoFinland</display-name>

      <uri>sip:summervacation@poc.example.com</uri>

</group>

</group-advertisement>

群组公告XML文档基于XML1.0且使用UTF-8编码。由OMA PoC控制面文档定义的元素的命名空间URI是URN,采用了命名空间标识“oma”。这个URN是um:oma:params:xml:ns:poc:group-advertisemento在群组公告的XML文档中关键的PoC元素是：

•vnote>元素发送方填入的公告文本；

•<group>元素——包含组类型有关的信息(拨入，拨出，其他)，PoC组务的显示名字，PoC组的URI。

当类型属性使用“拨入”时，说明是聊天PoC组。类似的，“拨出”意味着是预建立PoC组。增加了“其他”用于以后扩展[OMA PoC ControlPlane]。

在OMA PoC规范中，PoC客户端和PoC服务器是否支持这个特性是可选的。主控PoC服务器可以支持传递群组公告给所有的PoC群组成员，也可以实施不同的认证规则，规定允许谁能够向所有群组成员发送群组公告信息。最明显的认证规则是：

• 只有群组拥有者才能向所有群组成员发送群组公告信息；

• 所有群组成员都能向所有群组成员发送群组公告信息。

如果PoC客户端不想接收群组公告信息，它应该在SIPREGIRSTER请求中不包含PoC特性标签"+g.poc.groupad”。

6.2.7 阻塞特性

在6.2.4节指出，PoC用户可以利用访问控制列表，选择性地阻塞PoC呼入会话。此外，PoC用户能够指示PoC服务器拒绝所有新增的呼入PoC会话。这个特性称为ISB（Incoming Session Barring,呼入会话阻塞）。当激活阻塞特性时，参与PoC服务器将利用SIP480 Temporarily Unavailable响应拒绝所有呼入会话请求，与此同时，参与PoC服务器将保持进行中的PoC会话不受影响，并向用户传递呼入即时个人警示。如果用户还想阻塞即时个人警示，那么他应当激活InstantPersonal Alert Barring即时个人警示阻塞。6.4节描述阻塞功能的激活和去激活过程。

6.2.8 参与方信息

PoC用户可以请求PoC会话参与方的信息，及其他们在PoC会话中的状态。PoC客户端使用会议状态事件包来获知PoC参与方的变化：换而言之，通过通知单，用户能够获知谁加入或谁离开了会议。这个事件包还允许参与方获知用户参与会议的状态（挂起，告警）。

用户通过向标识了主控PoC服务器会议的URI发送SIP SUBCRIBE请求，就能够订阅会议状态。主控PoC服务器承担消息包通知方的任务。

这个事件包的名为“会议”。这个标志出现在SUBSCRIBE请求的Event头字黑段中。通知的正文中携带了会议状态信息文档，采用了[Draft-ietf^sipping-conference-package]定义的MIME类型"application/conference-info+xml。PoC Release1.0版的规范只用了提供功能的有限子集，如下所示：

• PoC群组标识；

• PoC用户标识现在是PoC会话的一部分；

• PoC用户状态（已连接，连接断开，挂起，告警）。