CN102104608B - 业务控制方法以及统一通信***和呼叫处理服务器 - Google Patents
业务控制方法以及统一通信***和呼叫处理服务器 Download PDFInfo
- Publication number
- CN102104608B CN102104608B CN201110062032.0A CN201110062032A CN102104608B CN 102104608 B CN102104608 B CN 102104608B CN 201110062032 A CN201110062032 A CN 201110062032A CN 102104608 B CN102104608 B CN 102104608B
- Authority
- CN
- China
- Prior art keywords
- entity
- entity class
- business
- call processing
- phone
- 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.)
- Active
Links
Images
Landscapes
- Telephonic Communication Services (AREA)
Abstract
本发明公开了一种业务控制方法以及统一通信***和呼叫处理服务器。本发明通过在SIP信令中携带实体类别而使通信实体能够识别对端的实体类别、还可使呼叫处理服务器在转发SIP信令的过程识别通信实体的实体类别；从而，SIP会话的某些通信实体能够依据本端的实体类别和对端的实体类别对当前SIP会话是否存在冲突作出判断、以决定向对端作出成功或者失败应答，或者，呼叫处理服务器也可依据SIP会话两端的通信实体类别判断当前SIP会话是否与实现某种业务的流程出现冲突、以决定是否实施或者如何实施。如此一来，就能够在一定程度上避免统一通信系中的多种业务之间可能存在的冲突。
Description
技术领域
本发明涉及统一通信技术，特别涉及用于统一通信的一种业务控制方法，以及，可实现业务控制的一种统一通信***和用于统一通信的一种呼叫处理服务器。
背景技术
统一通信是当前基于IP网络实现的一种应用***的总称，该应用***中集成了语音、图像、实时消息、语音邮件等多种媒体流的交互，并由于其高效、高宽带、高集成性、保护已有投资和低成本等优势而日益受到运营商和企业用户的欢迎。
目前，在统一通信中普遍使用的协议是初始会话协议(Session InitiationProtocol，SIP)，该协议属于一种应用层协议，并主要用于在IP网络中的两个端点之间建立和维护上述多种媒体流的链路，所述的链路也可称之为会话。实际应用中，会话的两个端点之间需要先通过SIP信令的交互，协商和确定媒体流通信的端口号、编解码的算法、媒体流的承载协议，然后，再独立于SIP信令来传输媒体流。从应用层的角度来看，会话的两个端点之间的媒体流是点对点直接传输的，SIP信令是由IP网络中部署的代理服务器转发的，无论媒体流还是SIP信令都是由传输层协议承载的。
图1中示出了一个统一通信***的一种应用场景。在图1中，统一通信***包括IP话机、PC终端，还包括：
呼叫处理服务器，其主要用于处理SIP信令的转接和路由；
统一信报服务器，其主要用于处理基于SIP信令的即时消息，例如语音邮箱、传真业务等；
会议服务器，其主要用于实现语音的混音功能，IP话机通过呼叫会议服务器内部定义的会议节点即可召开电话会议；
网关服务器，其主要用于实现统一通信***与其它类型网络***的互联；
视频服务器，其主要用于进行视频流相关业务。
如上可见，利用统一通信***能够同时实现多种业务。但在实际应用中，多种业务之间也可能存在冲突。
例如，某一IP话机B呼入会议服务器、并成功建立与会议节点A的连接。如果该话机B配置了呼叫保持音乐(Music On Hold，MOH)业务，则当用户在该话机B通过呼叫保持按键启用MOH业务后，呼叫处理服务器会根据MOH业务的流程将会议节点A与MOH节点连接，从而，由MOH节点向会议节点发送呼叫保持音乐。但此时，由于会议服务器的会议节点A是混音节点，因而该呼叫保持音乐会被转发到与该会议节点A建立连接的所有与会话机并播放，从而影响电话会议的召开。
再例如，会议服务器的会议节点A被配置为主动向某一IP话机C的外拨呼叫，而该IP话机C又被配置有可将呼叫前转到语音信箱的呼叫前转业务，如果IP话机C的用户没有及时摘机，则呼叫处理服务器就会将会议节点A的外拨呼叫前转到语音邮箱，语音邮箱也会向会议节点A播送提示菜单，同样也会影响会议召开。
通常，MOH节点和语音邮箱由统一信报服务器实现。
发明内容
有鉴于此，本发明提供了用于统一通信的一种业务控制方法，以及，可实现业务控制的一种统一通信***和用于统一通信的一种呼叫处理服务器。
本发明提供的一种业务控制方法，包括：
呼叫处理服务器和/或任意通信实体接收当前业务对应的其他通信实体发送的携带有实体类别的SIP信令，并由呼叫处理服务器或该任意通信实体依据对实体类别的识别使业务有选择性地被实施、以避免当前业务的冲突。
该业务控制方法通过业务发起流程使呼叫处理服务器被动地接收携带有实体类别的SIP信令、或者使呼叫处理服务器和通信实体被动地接收携带有实体类别的SIP信令。
业务发起流程中所使用的携带实体类别的SIP信令包括下述之一或任意组合：INVITE消息、200 OK消息、以及ACK消息；
该业务控制方法预先在INVITE消息、200 OK消息、ACK消息中定义出用于表示实体类别的P-Asserted-Identity-Type头域，并在INVITE消息、200 OK消息、ACK消息的P-Asserted-Identity-Type头域中携带实体类别；
或者，该业务控制方法预先在INVITE消息、200 OK消息、ACK消息的P-Asserted-Identity头域中定义出用于表示实体类别的一Type字段，并在INVITE消息、200 OK消息、ACK消息的P-Asserted-Identity头域的该Type字段中携带实体类别。
该业务控制方法通过订阅流程使呼叫处理服务器和/或通信实体主动要求获取携带有实体类别的SIP信令。
订阅流程中使用SUBSCRIBE消息主动要求获取携带于SIP信令的实体类别，并使用NOTIFY消息携带实体类别；
该业务控制方法预先在SUBSCRIBE消息和NOTIFY消息中定义出用于表示实体类别的P-Asserted-Identity-Type头域，在SUBSCRIBE消息和NOTIFY消息用于订阅实体类别时，SUBSCRIBE消息和NOTIFY消息的EVENT头域中标记出P-Asserted-Identity-Type头域、NOTIFY消息的消息体中还包括携带实体类别的P-Asserted-Identify-Type头域；
或者，该业务控制方法预先在SUBSCRIBE消息和NOTIFY消息的P-Asserted-Identity头域中定义出用于表示实体类别的一Type字段，在SUBSCRIBE消息和NOTIFY消息用于订阅实体类别时，SUBSCRIBE消息和NOTIFY消息的EVENT头域中标记出P-Asserted-Identify头域、NOTIFY消息的消息体中还包括所述Type字段携带实体类别的P-Asserted-Identify头域。
所述实体类别至少包括：用户代理类别、以及用于提供业务的服务器类别。
该业务控制方法由呼叫处理服务器依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器变更两端通信实体中的其中一个服务器类别的通信实体、以避免业务冲突。
所述当前业务为MOH业务；所述通信实体包括：服务器类别的会议节点、被变更的用于以播放呼叫保持音乐的方式提供MOH业务的服务器类别的MOH节点、以及变更后的用于以静默播放呼叫保持音乐的方式提供MOH业务的服务器类别的静默MOH节点。
该业务控制方法由呼叫处理服务器依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器禁止与两端通信实体中的其中一个服务器类别的通信实体针对当前业务建立媒体流连接、以避免业务冲突。
所述当前业务为MOH业务；所述通信实体包括：服务器类别的会议节点、以及被禁止的用于以播放呼叫保持音乐的方式提供MOH业务的服务器类别的MOH节点。
该业务控制方法由两端通信实体中的其中一个服务器类别的通信实体依据对实体类别的识别判断出当前业务可能导致业务冲突，并由执行所述判断的服务器类别的通信实体向对端的通信实体作失败应答，以使得可能导致业务冲突的业务被禁止实施。
所述当前业务为MOH业务；所述通信实体包括：服务器类别的会议节点、以及执行所述判断的用于以播放呼叫保持音乐的方式提供MOH业务的服务器类别的MOH节点。
本发明提供的一种统一通信***，至少包括呼叫处理服务器、以及除所述呼叫处理服务器之外的其他若干通信实体，其中，
呼叫处理服务器和/或任意通信实体接收当前业务对应的其他通信实体发送的携带有实体类别的SIP信令；
以及，呼叫处理服务器或该任意通信实体依据对实体类别的识别使业务有选择性地被实施、以避免业务冲突。
呼叫处理服务器在业务发起流程中被动地接收携带有实体类别的SIP信令，或者，呼叫处理服务器和通信实体在业务发起流程中被动地接收携带有实体类别的SIP信令。
业务发起流程中所使用的携带实体类别的SIP信令包括下述之一或任意合：INVITE消息、200 OK消息、以及ACK消息；
该统一通信***中预先在INVITE消息、200 OK消息、ACK消息中定义有用于表示实体类别的P-Asserted-Identity-Type头域，并在INVITE消息、200 OK消息、ACK消息的P-Asserted-Identity-Type头域中携带实体类别；
或者，该统一通信***中预先在INVITE消息、200 OK消息、ACK消息的P-Asserted-Identity头域中定义出用于表示实体类别的一Type字段，并在INVITE消息、200 OK消息、ACK消息的P-Asserted-Identity头域的该Type字段中携带实体类别。
呼叫处理服务器和/或通信实体通过订阅流程主动要求获取携带有实体类别的SIP信令。
订阅流程中使用SUBSCRIBE消息主动要求获取携带于SIP信令的实体类别，并使用NOTIFY消息携带实体类别；
该统一通信***预先在SUBSCRIBE消息和NOTIFY消息中定义有用于表示实体类别的P-Asserted-Identity-Type头域，在SUBSCRIBE消息和NOTIFY消息用于订阅实体类别时，SUBSCRIBE消息和NOTIFY消息的EVENT头域中标记出P-Asserted-Identity-Type头域、NOTIFY消息的消息体中还包括携带实体类别的P-Asserted-Identify-Type头域；
或者，该统一通信***中预先在SUBSCRIBE消息和NOTIFY消息的P-Asserted-Identity头域中定义出用于表示实体类别的一Type字段，在SUBSCRIBE消息和NOTIFY消息用于订阅实体类别时，SUBSCRIBE消息和NOTIFY消息的的EVENT头域中标记出P-Asserted-Identify头域、NOTIFY消息的消息体中还包括所述Type字段携带实体类别的P-Asserted-Identify头域。
所述实体类别至少包括：用户代理类别、以及用于提供业务的服务器类别。
该统一通信***中由呼叫处理服务器依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器变更两端通信实体中的其中一个服务器类别的通信实体、以避免业务冲突。
所述当前业务为MOH业务；所述通信实体包括：服务器类别的会议节点、被变更的用于以播放呼叫保持音乐的方式提供MOH业务的服务器类别的MOH节点、以及变更后的用于以静默播放呼叫保持音乐的方式提供MOH业务的服务器类别的静默MOH节点。
该统一通信***中由呼叫处理服务器依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器禁止与两端通信实体中的其中一个服务器类别的通信实体针对当前业务建立媒体流连接、以避免业务冲突。
所述当前业务为MOH业务；所述通信实体包括：服务器类别的会议节点、以及被禁止的用于以播放呼叫保持音乐的方式提供MOH业务的服务器类别的MOH节点。
该统一通信***中由两端通信实体中的其中一个服务器类别的通信实体依据对实体类别的识别判断出当前业务可能导致业务冲突，并由执行所述判断的服务器类别的通信实体向对端的通信实体作失败应答，以使得可能导致业务冲突的业务被禁止实施。
所述当前业务为MOH业务；所述通信实体包括：服务器类别的会议节点、以及执行所述判断的用于以播放呼叫保持音乐的方式提供MOH业务的服务器类别的MOH节点。
本发明提供的一种呼叫处理服务器，包括：
信令接收模块，接收当前业务对应的任意通信实体发送的携带有实体类别的SIP信令；
策略执行模块，依据对实体类别的识别使业务有选择性地被实施、以避免业务冲突。
所述信令接收模块在业务发起流程中被动地接收携带于SIP信令的实体类别。
业务发起流程中所使用的携带实体类别的SIP信令包括下述之一或任意组合：INVITE消息、200 OK消息、以及ACK消息；
INVITE消息、200 OK消息、ACK消息中预先定义有用于携带实体类别的P-Asserted-Identity-Type头域；
或者，INVITE消息、200 OK消息、ACK消息的P-Asserted-Identity头域中预先定义有用于携带实体类别的一Type字段。
所述信令接收模块在订阅流程中主动要求获取携带有实体类别的SIP信令。
订阅流程中使用SUBSCRIBE消息主动要求获取携带于SIP信令的实体类别，并使用NOTIFY消息携带实体类别；
SUBSCRIBE消息和NOTIFY消息中预先定义有用于表示实体类别的P-Asserted-Identity-Type头域，在SUB SCRIBE消息和NOTIFY消息用于订阅实体类别时，SUBSCRIBE消息和NOTIFY消息的EVENT头域中标记出P-Asserted-Identity-Type头域、NOTIFY消息的消息体中包括携带实体类别的P-Asserted-Identify-Type头域；
或者，SUBSCRIBE消息和NOTIFY消息的P-Asserted-Identity头域中预先定义有用于表示实体类别的一Type字段，在SUBSCRIBE消息和NOTIFY消息用于订阅实体类别时，SUBSCRIBE消息和NOTIFY消息的EVENT头域中标记出P-Asserted-Identify头域、NOTIFY消息的消息体中还包括所述Type字段携带实体类别的P-Asserted-Identify头域。
所述实体类别至少包括：用户代理类别、以及用于提供业务的服务器类别。
所述策略执行模块依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器变更两端通信实体中的其中一个服务器类别的通信实体、以避免业务冲突。
所述当前业务为MOH业务；所述通信实体包括：服务器类别的会议节点、被变更的用于以播放呼叫保持音乐的方式提供MOH业务的服务器类别的MOH节点、以及变更后的用于以静默播放呼叫保持音乐的方式提供MOH业务的服务器类别的静默MOH节点。
所述策略执行模块依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器禁止与两端通信实体中的其中一个服务器类别的通信实体针对当前业务建立媒体流连接、以避免业务冲突。
所述当前业务为MOH业务；所述通信实体包括：服务器类别的会议节点、以及被禁止的用于以播放呼叫保持音乐的方式提供MOH业务的服务器类别的MOH节点。
由上述技术方案可见，本发明通过在SIP信令中携带实体类别而使通信实体能够识别对端的实体类别、还可使呼叫处理服务器在转发SIP信令的过程识别通信实体的实体类别；从而，SIP会话的某些通信实体能够依据本端的实体类别和对端的实体类别对当前SIP会话是否存在冲突作出判断、以决定向对端作出成功或者失败应答，或者，呼叫处理服务器也可依据SIP会话两端的通信实体类别判断当前SIP会话是否与实现某种业务的流程出现冲突、以决定是否实施或者如何实施。如此一来，就能够在一定程度上避免统一通信系中的多种业务之间可能存在的冲突。
附图说明
图1为现有技术中的统一通信***的一种应用场景示意图；
图2a至图2f为SIP信令中携带实体类别的实现方式示意图；
图3a为在呼叫流程中实现本发明实施例的一实例流程图；
图3b为在订阅流程中实现本发明实施例的一实例流程图；
图4为一会话实例中建立通话过程的流程示意图；
图5为一会话实例在建立通话之后进行呼叫保持的流程示意图；
图6为一会话实例在继呼叫保持之后再次建立通话过程的流程示意图；
图7为一会话实例再次建立通话之后进行呼叫转移的流程示意图；
图8为如图5所示呼叫保持过程经本发明实施例改进之后的一种流程示意图；
图9为如图5所示呼叫保持过程经本发明实施例改进之后的另一种流程示意图；
图10为如图8所示呼叫保持过程的一种替换方案的流程示意图；
图11为如图8所示呼叫保持过程的另一种替换方案的流程示意图；
图12为如图9所示呼叫保持过程的一种替换方案的流程示意图；
图13为如图9所示呼叫保持过程的另一替换方案的流程示意图。
具体实施方式
为使本发明的目的、技术方案及优点更加清楚明白，以下参照附图并举实施例，对本发明进一步详细说明。
在本发明实施例中，可使通信实体能够识别对端的实体类别、和/或使呼叫处理服务器能够识别通信实体的实体类别，并呼叫处理服务器或该通信实体依据对实体类别的识别使业务有选择性地被实施、以避免当前业务的冲突。
为此，本发明实施例中定义了通信实体(例如话机、各种服务器等)的实体类别、并可将实体类别携带于SIP信令中。
这样，任一通信实体即可将本端的实体类别携带于SIP信令中提供给呼叫处理服务器，进一步地还可以由呼叫处理服务器沿呼叫路由将该通信实体的实体类别携带于SIP信令中提供给对端的通信实体，从而：
使得SIP会话某些通信实体(后文中详细说明)能够依据本端的实体类别和对端的实体类别对当前SIP会话是否存在冲突作出判断，从而决定向对端作出成功或者失败应答；
或，使得呼叫处理服务器可依据SIP会话两端的通信实体类别对当前SIP会话是否与实现某种业务而发起的流程出现冲突作出判断，从而决定是否实施、或者如何实施；
一个显著的例子是MOH业务，呼叫处理服务器会根据SIP会话的两端通信实体的实体类别进行有区别的处理。假设，IP话机B配置了MOH功能，如果IP话机B呼叫到一个电话会议节点中，之后向呼叫处理服务器发起呼叫保持功能，按照预定的MOH流程，呼叫处理服务器需要将电话会议节点连接到MOH节点；此后，MOH节点向电话会议节点播放呼叫保持音乐，因为电话会议节点是一个混音节点，但如此就会影响会议召开。如图4和图5中的流程所示，该流程中的IP话机A代表会议服务器的会议节点。
在SIP信令中携带通信实体的实体类别标识后，呼叫处理服务器可以识别出IP话机B发起呼叫保持功能所对应的是一个混音节点，从而对MOH业务的流程进行修正，可以将该呼叫保持业务拒绝，也可以将会议节点连接到一个静默(即不播放呼叫保持音乐)的MOH节点，实现IP话机B的呼叫保持业务，但又不影响电话会议。如图8或图9中的流程所示，该流程是针对图5中原有流程的修正。
为了使实体类别的定义更为灵活和多样化，本发明实施例中可以对实体类别采用分级定义的方式。
以分级定义共包含四级为例，实体类别的定义的具体格式可以为“aa.bb.cc.dd”。
其中，aa表示是第一级的实体类别，bb表示第二级的实体类别、第二级的实体类别属于第一级的实体类别之下的子类别，cc表示第三级的实体类别、第三级的实体类别属于第二级的实体类别之下的子类别，ee表示第四级的实体类别、第四级的实体类别属于第三级的实体类别之下的子类别。
优选地，第一级和第二级的实体类别是必须包含，而第三级和第四级的实体类别则是根据实际需要而可选的。
本实施例给出了如表1所示的第一级和第二级的实体类别的一种具体实现方式。
表1
按照上述格式，即可在SIP信令中携带实体类别。另外，前文中提到某些通信实体能够依据本端的实体类别和对端的实体类别对当前SIP会话是否存在冲突作出判断、从而决定向对端作出成功或者失败应答，所述的某些通信实体主要是指实体类别为server的通信实体。
实际应用中，可以利用不同的SIP信令来携带实体类别。
例如，可以在呼叫流程中交互携带有实体类别的SIP信令，具体说，就可以至少利用INVITE消息、200 OK消息、以及ACK消息来携带实体类别。
在INVITE消息、200 OK消息、以及ACK消息中，具体的携带方式有两种：
其一，预先在INVITE消息、200 OK消息、以及ACK消息这些SIP信令中定义一种专用于表示实体类别的扩展头域，并利用扩展头域携带实体类别。
如图2a所示，本文将该扩展头域称为P-Asserted-Identity-Type头域，在P-Asserted-Identity-Type头域中即可直接携带实体类别。
以如表1所示的格式为例，P-Asserted-Identity-Type头域的格式可以表示为“P-Asserted-Identity-Type：ua.phone”、或“P-Asserted-Identity-Type：server.mixer”。
其二，预先在INVITE消息、200 OK消息、以及ACK消息这些SIP信令中现有的P-Asserted-Identity头域中定义一种专用于表示实体类别的扩展字段，并利用该扩展字段携带实体类别。
如图2b所示，本文将该扩展字段称为Type字段，在P-Asserted-Identity头域的Type字段即可携带实体类别。
仍以如表1所示的格式为例，P-Asserted-Identity头域及该P-Asserted-Identity头域中的Type字段的格式可以表示为“P-Asserted-Identity：<sip:1030192.168.58.160：5060；type＝ua.phone>”、或“P-Asserted-Identity：<sip:5000192.168.18.122：5060；type＝server.mixer>”。
由于RFC3261中详细定义了SIP信令的报文格式，因而本文对于SIP信令的其他部分不再予以赘述。
利用上述INVITE消息、200 OK消息、以及ACK消息，包括呼叫处理服务器在内的通信实体是被动地接收并识别实体类别。但是，包括呼叫处理服务器在内的任何一个通信实体还可以通过订阅流程主动地订阅对端通信实体类别。订阅和通知实体类别的SIP信令分别是SUBSCRIBE消息和NOTIFY消息。
在SUBSCRIBE消息、以及NOTIFY消息中，具体的携带方式也有两种：
其一，预先在SUBSCRIBE消息、以及NOTIFY消息这些SIP信令中定义一种专用于表示实体类别的前述P-Asserted-Identity-Type头域。
如图2c所示，发起订阅的通信实体利用SUBSCRIBE消息来发出要订阅的项目，EVENT头域中标记出了P-Asserted-Identity-Type头域、以表明订阅的项目是实体类别；
如图2d所示，被订阅的通信实体以NOTIFY消息给出订阅的应答，EVENT头域中标记出了P-Asserted-Itendity-Type头域、以表示是对实体类别的订阅的应答，且，NOTIFY消息的消息体中还包括携带实体类别的P-Asserted-Identify-Type头域。
以如表1所示的格式为例，P-Asserted-Identity-Type头域的格式仍可以表示为“P-Asserted-Identity-Type：ua.phone”、或“P-Asserted-Identity-Type：server.mixer”。
其二，预先在SUBSCRIBE消息、以及NOTIFY消息这些SIP信令中现有的P-Asserted-Identity头域中定义一种专用于表示实体类别的前述Type字段，并利用该Type字段携带实体类别。
如图2e所示，发起订阅的通信实体利用SUBSCRIBE消息来发出要订阅的项目，EVENT头域中标记出了P-Asserted-Identity头域、以表明订阅的项目是包含有实体类别的实体信息；
如图2f所示，被订阅的通信实体以NOTIFY消息给出订阅的应答，EVENT头域中标记出了P-Asserted-Itendity头域、以表示是对包含有实体类别的实体信息的订阅的应答，且，NOTIFY消息的消息体中还包括P-Asserted-Identify头域，该P-Asserted-Identify头域中包括Type字段，该Type字段携带有实体类别。
仍以如表1所示的格式为例，P-Asserted-Identity头域及该P-Asserted-Identity头域中的Type字段的格式可以表示为“P-Asserted-Identity：<sip:1030192.168.58.160：5060；type＝ua.phone>”、或“P-Asserted-Identity：<sip:5000192.168.18.122：5060；type＝server.mixer>”。
图3a为在呼叫流程中实现本发明实施例的一实例流程图。如图3a所示，以SIP会话两端的通信实体为IP话机A和IP话机B为例，本实施例中可实现实体类别识别的呼叫流程包括如下步骤：
S311，IP话机A发起呼叫流程，向呼叫处理服务器发送携带有会话描述协议(SDP)的INVITE消息，并在INVITE消息的P-Asserted-Identity-Type头域中携带本端的实体类别ua.phone、或在P-Asserted-Identity头域的Type字段中携带本端的实体类别ua.phone。根据RFC3261协议，该INVITE消息指明了被叫IP话机B的统一资源标识符(URI)信息。
经过本步骤，呼叫处理服务器能够获知IP话机A的实体类别为ua.phone。
S312，呼叫处理服务器针对IP话机A所发送的INVITE消息，向IP话机A回应100 Trying消息。
S313，呼叫处理服务器依据IP话机A所发送的INVITE消息中携带的IP话机B的URI信息，获知IP话机A希望与IP话机B建立媒体流连接、并向IP话机B发送携带有SDP的INVITE消息，并在INVITE消息的P-Asserted-Identity-Type头域中携带IP话机A的实体类别ua.phone、或在P-Asserted-Identity头域的Type字段中携带IP话机A的实体类别ua.phone。
经过本步骤，IP话机B就能够获知IP话机A的实体类别为ua.phone。
S314，IP话机B针对呼叫处理服务器所发送的INVITE消息，向呼叫处理服务器回应100 Trying消息。
S315，IP话机B向呼叫处理服务器发送180 Ringing消息。
S316，呼叫处理服务器向IP话机A发送180 Ringing消息。
S317，IP话机B针对呼叫处理服务器在S313发送的INVITE消息，向呼叫处理服务器发送携带有SDP的200 OK消息，并在200 OK消息的P-Asserted-Identity-Type头域中携带本端的实体类别ua.phone、或在P-Asserted-Identity头域的Type字段中携带本端的实体类别ua.phone。
经过本步骤，呼叫处理服务器能够获知IP话机B的实体类别为ua.phone。
S318，呼叫处理服务器针对IP话机A在S311发送的INVITE消息，向IP话机A发送携带有SDP的200 OK消息，并在200 OK消息的P-Asserted-Identity-Type头域中携带IP话机B的实体类别ua.phone、或在P-Asserted-Identity头域的Type字段中携带IP话机B的实体类别ua.phone。
经过本步骤，IP话机A就能够获知IP话机B的实体类别为ua.phone。
S319，IP话机A针对呼叫处理服务器在S318发送的200 OK消息，向呼叫处理服务器回应ACK消息，可选地，IP话机A还可以在该ACK消息的P-Asserted-Identity-Type头域中携带本端的实体类别ua.phone、或在P-Asserted-Identity头域的Type字段中携带本端的实体类别ua.phone。
S320，呼叫处理服务器针对IP话机B在S317发送的200 OK消息，向IP话机B发送ACK消息，可选地，呼叫处理服务器还可以在该ACK消息的P-Asserted-Identity-Type头域中携带IP话机A的实体类别ua.phone、或在P-Asserted-Identity头域的Type字段中携带IP话机A的实体类别ua.phone。
S321，IP话机A与IP话机B之间建立媒体流连接。
在本步骤之前，IP话机A和IP话机B的用于建立媒体流连接的信息，已按照RFC3261中详细定义的SIP信令的交互规程、以及通信实体之间的会话标记方式，由呼叫处理服务器转发给双方(例如，上述信息可以携带于SDP中)，从而在本步骤中，IP话机A和IP话机B能够获知对端的用于建立媒体流连接的信息，因而使本步骤能够在IP话机A与IP话机B之间建立媒体流连接。
至此，可实现实体类别识别的呼叫流程结束。
由于IP话机A与IP话机B的实体类别均为ua.phone，因而如果实体类别均为ua.phone的两个通信实体之间的正常会话业务不会导致冲突产生，呼叫处理服务器不会拒绝在IP话机A与IP话机B之间的正常会话业务的实施，进而，如果IP话机A或者IP话机B发起该会话内的其他业务，且呼叫处理服务器判断出该其他业务是两端支持的业务，则正常实施；否则进行适当动作。
此外，由于RFC3261中详细定义了SIP信令的交互规程、以及通信实体之间的会话标记方式，因而，本文对于交互规程中涉及的对本发明实施例无实质影响的例如100 Trying消息各类消息、某些消息中需要带有SDP的情况、以及例如通信实体之间的会话标记方式(即呼叫标识符)等其他处理过程，本文均不再赘述。本文后续所描述的流程同理。
而且，对于不同的通信实体发起呼叫的情况，上述流程可能会需要进行适当的调整，而对于具体如何调整，本领域技术人员能够基于如图2所示流程的启示、并结合RFC3261中详细定义的现有交互规程予以实现，本文不再一一列举。
图3b为在订阅流程中实现本发明实施例的一实例流程图。如图3b所示，仍以SIP会话两端的通信实体为IP话机A和IP话机B为例，本实施例中可实现实体类别识别的订阅流程包括如下步骤：
S331，IP话机A发起订阅流程，向呼叫处理服务器发送SUBSCRIBE消息，并将SUBSCRIBE消息的EVENT头域的取值标注为P-Asserted-Identity-Type、或P-Asserted-Identity。本步骤中，取值标注为P-Asserted-Identity-Type时，明确表示订阅的项目是对端的实体类别；取值标注为P-Asserted-Identity时，表明订阅的项目是对端的实体信息，当然，该实体信息中包括对端的实体类别。根据RFC3261协议，该SUBSCRIBE消息指明作为被订阅目标的IP话机B的URI信息。
S332，呼叫处理服务器向IP话机A回应200 OK消息，其中，本步骤中的200 OK消息并不携带实体类别。
S333，呼叫处理服务器依据IP话机A所发送的SUBSCRIBE消息中携带的作为被订阅目标的IP话机B的URI信息，获知IP话机A希望订阅IP话机B的实体类别、在SUBSCRIBE消息的EVENT头域中标注出P-Asserted-Identity-Type、或P-Asserted-Identity。
S334，IP话机B向呼叫处理服务器回应200 OK消息，其中，200 OK消息并不携带实体类别。
S335，IP话机B向呼叫处理服务器发送NOTIFY消息，并将NOTIFY消息的EVENT头域的取值标注为P-Asserted-Identity-Type、或P-Asserted-Identity，还在NOTIFY消息的消息体中以P-Asserted-Identity-Type头域的形式、或者以包含有Type字段的P-Asserted-Identity头域的形式携带本端的实体类别ua.phone。
经过本步骤，呼叫处理服务器能够获知IP话机B的实体类别为ua.phone。
S336，呼叫处理服务器向IP话机B回应200 OK消息，其中，本步骤中的200 OK消息并不携带实体类别。
S337，呼叫处理服务器向IP话机A发送NOTIFY消息，并在NOTIFY消息的EVENT头域中标注出P-Asserted-Identity-Type头域、或P-Asserted-Identity头域，还在NOTIFY消息的消息体中以P-Asserted-Identity-Type头域的形式、或者以包含有Type字段的P-Asserted-Identity头域的形式携带IP话机B的实体类别ua.phone。
经过本步骤，IP话机A就能够获知IP话机B的实体类别为ua.phone。
S338，IP话机A向呼叫处理服务器回应200 OK消息，其中，本步骤中的200 OK消息并不携带实体类别。
至此，可实现实体类别识别的订阅流程结束。
由于IP话机A与IP话机B的实体类别均为ua.phone，因而如果实体类别均为ua.phone的两个通信实体之间的任一种业务不会导致冲突产生，则呼叫处理服务器不会拒绝在IP话机A与IP话机B之间的正常会话业务的实施，进而，如果IP话机A或者IP话机B发起会话内的其他业务，且呼叫处理服务器判断出该其他业务是两端支持的业务，则正常实施；否则进行适当动作。
此外，IP话机B也可以按照与IP话机A相同的方式发起订阅流程，从而也能够获知IP话机A的实体类别为ua.phone。除此之外，呼叫处理服务器也可以发起订阅流程。但是，对于不同的通信实体发起订阅的情况，上述流程有可能需要进行调整，而对于具体如何调整，本领域技术人员能够基于如图3所示流程的启示予以实现，本文不再一一列举。
下面，再结合MOH业务的实例，进一步说明本发明实施例中的业务控制方法为何能够避免业务间的冲突。
图4为一会话实例中建立通话过程的流程示意图。如图4所示，该会话实例中建立通话的流程包括如下步骤：
S401，IP话机B发起呼叫流程，向呼叫处理服务器发送携带有SDP的INVITE消息。该INVITE消息指明被叫的IP话机A的URI信息。
S402，呼叫处理服务器向IP话机B回应100 Trying消息。
S403，呼叫处理服务器依据IP话机B所发送的INVITE消息中携带的被叫的IP话机A的URI信息，获知IP话机B希望与IP话机A建立媒体流连接、并向IP话机A发送携带有SDP的INVITE消息。
S404，IP话机A向呼叫处理服务器回应100 Trying消息。
S405，IP话机A向呼叫处理服务器发送180 Ringing消息。
S406，呼叫处理服务器向IP话机B发送180 Ringing消息。
S407，IP话机A针对呼叫处理服务器在S403发送的INVITE消息，向呼叫处理服务器发送携带有SDP的200 OK消息。
S408，呼叫处理服务器针对IP话机B在S401发送的INVITE消息，向IP话机B发送携带有SDP的200 OK消息。
S409，IP话机B针对呼叫处理服务器在S408发送的200 OK消息，向呼叫处理服务器回应ACK消息。
S410，呼叫处理服务器针对IP话机A在S407发送的200 OK消息，向IP话机A回应ACK消息。
S411，IP话机A与IP话机B之间建立媒体流连接。
在本步骤之前，IP话机A和IP话机B的用于建立媒体流连接的信息，已按照RFC3261中详细定义的SIP信令的交互规程、以及通信实体之间的会话标记方式，由呼叫处理服务器转发给双方(例如，上述信息可以携带于SDP中)，从而在本步骤中，IP话机A和IP话机B能够获知对端的用于建立媒体流连接的信息，因而使本步骤能够在IP话机A与IP话机B之间建立媒体流连接。
至此，IP话机A与IP话机B之间建立可用于通话的媒体流连接，但IP话机A与IP话机B并不知晓对端的实体类别、呼叫处理服务器也不知晓IP话机A和IP话机B的实体类别。
图5为一会话实例在建立通话之后进行呼叫保持的流程示意图。在如图5所示的流程中，IP话机B配置有MOH业务，而且，IP话机B为了将通话转接至IP话机C，启用了呼叫保持(例如按下IP话机的功能键)流程，从而由呼叫处理服务器将IP话机A与IP话机B之间的通话变成用户A与MOH节点之间的通话，该流程具体包括如下步骤：
S501，IP话机B发起MOH业务，向呼叫处理服务器发送INVITE消息。该INVITE消息中携带有表示呼叫保持的标记，例如，该INVITE消息的SDP中携带的IP地址为0.0.0.0、或者携带的端口号为0。根据RFC3261协议，该INVITE消息指明所针对的IP话机A的URI信息、并携带图4中已经建立的会话的呼叫标识符。
S502，呼叫处理服务器向IP话机B回应100 Trying消息。
S503，呼叫处理服务器依据IP话机B所发送的INVITE消息中携带的IP话机A的URI信息和图4中已经建立的会话的呼叫标识符，获知IP话机B希望将IP话机A呼叫保持、并向IP话机A发送INVITE消息。此INVITE消息中不带SDP，期望IP话机A在返回的200 OK消息中携带SDP、并利用返回的200 OK消息中携带的SDP给出媒体流连接信息。
S504，IP话机A向呼叫处理服务器回应携带有SDP的200 OK消息。
S505，呼叫处理服务器向统一信报服务器的MOH节点发送携带有S504中由IP话机A给出的SDP的INVITE消息。
S506，MOH节点向呼叫处理服务器回应100 Trying消息。
S507，MOH节点向呼叫处理服务器发送Session Progress消息。
S508，MOH节点向呼叫处理服务器发送携带有SDP的200 OK消息。
S509，呼叫处理服务器向MOH节点回应ACK消息。
S510，呼叫处理服务器针对在S504中从IP话机A接收到的200 OK消息，向IP话机A回应携带有S508中由MOH节点给出的SDP的ACK消息。
S511，IP话机A与MOH节点之间建立媒体流连接。
在本步骤之前，IP话机A和MOH节点的用于建立媒体流连接的信息，已按照RFC3261中详细定义的SIP信令的交互规程、以及通信实体之间的会话标记方式，由呼叫处理服务器转发给双方(例如，上述信息可以携带于SDP中)，从而在本步骤中，IP话机A和MOH节点能够获知对端的用于建立媒体流连接的信息，因而使本步骤能够在IP话机A与MOH节点之间建立媒体流连接。
S512，呼叫处理服务器针对IP话机B在S501所发送的INVITE消息，向IP话机B回应携带有SDP的200 OK消息。该SDP中携带有表示呼叫保持的标记(即IP地址为0.0.0.0或者端口为0)，表示将IP话机B呼叫保持。
S513，IP话机B向呼叫处理服务器回应ACK消息。
至此，IP话机A与IP话机B之间的通话变成IP话机A与MOH节点之间的通话，并由MOH节点通过媒体流连接向IP话机A播放保持音乐。
图6为一会话实例在继呼叫保持之后再次建立通话过程的流程示意图。如图6所示，IP话机B保持住原有呼叫后即直接连接至IP话机C，具体包括如下步骤：
S601，IP话机B发起呼叫流程，向呼叫处理服务器发送携带有SDP的INVITE消息。该INVITE消息指明被叫的IP话机C的URI信息，被叫的IP话机C所在的一路呼叫是区别于图4中已建立的原有呼叫的一路新呼叫、并拥有新的呼叫标识符。
S602，呼叫处理服务器向IP话机B回应100 Trying消息。
S603，呼叫处理服务器依据IP话机B所发送的INVITE消息中携带的被叫的IP话机C的URI信息，获知IP话机B希望与IP话机C建立媒体流连接、并向IP话机C发送INVITE消息。
S604，IP话机C向呼叫处理服务器回应100 Trying消息。
S605，IP话机C向呼叫处理服务器发送180 Ringing消息。
S606，呼叫处理服务器向IP话机B发送180 Ringing消息。
S607，IP话机C针对呼叫处理服务器在S603发送的INVITE消息，向呼叫处理服务器回应携带有SDP的200 OK消息。
S608，呼叫处理服务器针对IP话机B在S601发送的INVITE消息，向IP话机B回应携带有SDP的200 OK消息。
S609，IP话机B向呼叫处理服务器回应ACK消息。
S610，呼叫处理服务器针对IP话机C在S607发送的200 OK消息，向IP话机C回应ACK消息。
S611，IP话机B与IP话机C之间建立媒体流连接。
在本步骤之前，IP话机B和IP话机C的用于建立媒体流连接的信息，已按照RFC3261中详细定义的SIP信令的交互规程、以及通信实体之间的会话标记方式，由呼叫处理服务器转发给双方(例如，上述信息可以携带于SDP中)，从而在本步骤中，IP话机B和IP话机C能够获知对端的用于建立媒体流连接的信息，因而使本步骤能够在IP话机B与IP话机C之间建立媒体流连接。
至此，IP话机B与IP话机C之间建立可用于通话的媒体流连接，但IP话机B与IP话机C并不知晓对端的实体类别、呼叫处理服务器也不知晓IP话机B和IP话机C的实体类别。
图7为一会话实例再次建立通话之后进行呼叫转移的流程示意图。如图7所示，IP话机B在连接至IP话机C之后，继续将IP话机C再转移至IP话机A，具体包括如下步骤：
S701，IP话机B发起转接流程，向呼叫处理服务器发送REFER消息。该REFER消息中指明将此前在图6中建立的IP话机B与IP话机C的连接转移为IP话机A与IP话机C的连接。
S702，呼叫处理服务器向IP话机B回应100 Trying消息。
S703，呼叫处理服务器向IP话机B回应ACCEPT消息。
S704，呼叫处理服务器依据IP话机B所发送的REFER消息中携带的IP话机A的URI信息和呼叫标识符，获知IP话机B希望将IP话机C转移至IP话机A、并首先向IP话机A发送INVITE消息。该INVITE消息不携带SDP，期望IP话机A在返回的200 OK消息中携带SDP，并利用返回的200 OK消息中携带的SDP给出媒体流连接信息。
S705，IP话机A向呼叫处理服务器回应携带有SDP的200 OK消息。
S706，呼叫处理服务器依据S705中由IP话机A给出的SDP，向IP话机C发送携带该SDP的INVITE消息。该INVITE消息实际上可以理解为此前在图6中已建立的IP话机B与IP话机C的对话内RE-INVITE消息。
S707，IP话机C向呼叫处理服务器回应携带有SDP的200 OK消息。
S708，呼叫处理服务器向IP话机C回应ACK消息。
S709，呼叫处理服务器向IP话机B发送NOTIFY消息，通知IP话机B已完成转接。
S710，呼叫处理服务器针对IP话机A在S705发送的200 OK消息，向IP话机A回应携带SDP的ACK消息。该SDP是S707中由IP话机C给出的SDP。
S711，IP话机A与IP话机C之间建立媒体流连接。
在本步骤之前，IP话机A和IP话机C的用于建立媒体流连接的信息，已按照RFC3261中详细定义的SIP信令的交互规程、以及通信实体之间的会话标记方式，由呼叫处理服务器转发给双方(例如，上述信息可以携带于SDP中)，从而在本步骤中，IP话机A和IP话机C能够获知对端的用于建立媒体流连接的信息，因而使本步骤能够在IP话机A与IP话机C之间建立媒体流连接。
S712，呼叫处理服务器向IP话机B发送BYE消息，以使IP话机B断开与IP话机C之间的连接。其中，本步骤中的BYE消息携带有图6中已建立的IP话机B与IP话机C之间的会话的呼叫标识符，从而能够使IP话机B获知需要断开与IP话机C之间的连接。
S713，IP话机B向呼叫处理服务器回应200 OK消息，确认IP话机B已断开与IP话机C之间的连接。
S714，呼叫处理服务器向IP话机B发送BYE消息，以使IP话机B断开与IP话机A之间的连接。其中，本步骤中的BYE消息携带有图4中已建立、但在图5中变为呼叫保持状态的IP话机B与IP话机A之间的会话的呼叫标识符，从而能够使IP话机B获知需要断开与IP话机A之间的连接。
S715，IP话机B向呼叫处理服务器回应200 OK消息，确认IP话机B已断开与IP话机A之间的连接。
S716，呼叫处理服务器向MOH节点发送BYE消息，以使MON节点断开与IP话机A之间的连接。
S717，MOH节点向呼叫处理服务器回应200 OK消息，确认断开与IP话机A之间的连接。
至此，IP话机B与IP话机C之间的通话变成IP话机A与IP话机C之间的通话。
上述如图4至图7所示的实例，能够实现IP话机B与IP话机A之间的通话、IP话机B启用呼叫保持、IP话机B连接至IP话机C、IP话机C与IP话机B之间的通话转移至IP话机A。实际上如图4至图7的整个流程完成的是有通知呼叫转移的业务。
但是，如果IP话机A不是真正的话机，而是会议服务器中的会议节点，IP话机B是普通用户节点，则按照如图5所示流程，IP话机B启用呼叫保持、IP话机A与MOH节点建立媒体流连接之后，由MOH节点向IP话机A播放的保持音乐会影响到会议的召开。
相比之下，如果采用本发明实施例中的方案，则不会导致上述问题出现。
图8为如图5所示呼叫保持过程经本发明实施例改进之后的一流程示意图。如图8所示：
S801，IP话机B发起MOH业务，向呼叫处理服务器发送携带有SDP的INVITE消息。该INVITE消息中携带有表示呼叫保持的标记，例如，该INVITE消息的SDP中携带的IP地址为0.0.0.0、或者携带的端口号为0。该INVITE消息中指明所针对的IP话机A的URI信息、并携带图4中已经建立会话的呼叫标识符。
S802，呼叫处理服务器向IP话机B回应100 Trying消息。
S803，呼叫处理服务器依据IP话机B所发送的INVITE消息中携带的IP话机A的URI信息和图4中已经建立会话的呼叫标识符，获知IP话机B希望将IP话机A呼叫保持、并向作为会议节点的IP话机A发送INVITE消息。该INVITE消息不带SDP，期望IP话机A在返回的200 OK消息中携带SDP，并利用返回的200 OK消息中携带的SDP给出IP话机A的媒体流连接信息。
S804，作为会议节点的IP话机A向呼叫处理服务器回应携带有SDP的200 OK消息，并在200 OK消息的P-Asserted-Identity-Type头域中携带IP话机A的实体类别server.mixer、或在P-Asserted-Identity头域的Type字段中携带IP话机A的实体类别server.mixer。
经过本步骤，呼叫处理服务器就能够获知作为会议节点的IP话机A的实体类别为server.mixer。
S805，由于实体类别为server.mixer的通信实体与作为对端通信实体的统一信报服务器的MOH节点(呼叫处理服务器中可以预先记录MOH节点的实体类别server.ums)连接后会产生影响会议召开的冲突，因此，呼叫处理服务器将MOH业务的实施方式变更为静默方式，并将本应作为对端通信实体的MOH节点变更为统一信报服务器的静默MOH节点，然后向静默MOH节点发送携带S804中由作为会议节点的IP话机A给出的SDP的INVITE消息、并在INVITE消息的P-Asserted-Identity-Type头域中携带IP话机A的实体类别server.mixer、或在P-Asserted-Identity头域的Type字段中携带IP话机A的实体类别server.mixer。
本步骤的处理过程就相当于呼叫处理服务器依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器变更两端通信实体(server类别的会议节点和server类别的MOH节点)中的其中一个用于以播放呼叫保持音乐的方式提供MOH业务的server类别的MOH节点，即，将用于以播放呼叫保持音乐的方式提供MOH业务的server类别的MOH节点，变更为用于以静默播放呼叫保持音乐的方式提供MOH业务的server类别的静默MOH节点。
经过本步骤，静默MOH节点能够获知作为会议节点的IP话机A的实体类别为server.mixer。
S806，静默MOH节点向呼叫处理服务器回应100 Trying消息。
S807，静默MOH节点向呼叫处理服务器发送Session Progress消息。
S808，静默MOH节点向呼叫处理服务器发送携带有SDP的200 OK消息，并在200 OK消息的P-Asserted-Identity-Type头域中携带该静默MOH节点的实体类别server.ums、或在P-Asserted-Identity头域的Type字段中携带该静默MOH节点的实体类别server.ums。
经过本步骤，呼叫处理服务器就能够获知静默MOH节点的实体类别为server.ums。
S809，呼叫处理服务器向静默MOH节点回应ACK消息。
S810，呼叫处理服务器针对在S804中从IP话机A接收到的200 OK消息，向作为会议节点的IP话机A回应携带有SDP的ACK消息，该SDP为S808中由静默MOH节点给出的SDP。可选地还可以在ACK消息的P-Asserted-Identity-Type头域中携带静默MOH节点的实体类别server.ums、或在P-Asserted-Identity头域的Type字段中携带静默MOH节点的实体类别server.ums。
S811，作为会议节点的IP话机A与静默MOH节点之间建立媒体流连接。
在本步骤之前，IP话机A和静默MOH节点的用于建立媒体流连接的信息，已按照RFC3261中详细定义的SIP信令的交互规程、以及通信实体之间的会话标记方式，由呼叫处理服务器转发给双方(例如，上述信息可以携带于SDP中)，从而在本步骤中，IP话机A和静默MOH节点能够获知对端的用于建立媒体流连接的信息，因而使本步骤能够在IP话机A与静默MOH节点之间建立媒体流连接。
S812，呼叫处理服务器针对IP话机B在S801发送的INVITE消息，向IP话机B回应携带有SDP的200 OK消息。该SDP中携带有表示呼叫保持的标记(即IP地址为0.0.0.0或者端口号0)，表示将IP话机B呼叫保持。
S813，IP话机B向呼叫处理服务器回应ACK消息。
至此，作为会议节点的IP话机A与作为普通节点的IP话机B之间的通话变成作为会议节点的IP话机A与静默MOH节点之间的通话，并由静默MOH节点通过媒体流连接向作为会议节点的IP话机A播放静默音，即实质上是不向会议节点发送任何有效声音，从而避免了会议收到保持音乐的影响。
也就是说，虽然静默MOH节点的实体类别与MOH节点的实体类别同样为server.ums，但由于此时呼叫处理服务器已根据会话中包含了实体类别为server.mixer的通信实体，而对MOH的业务流程进行了既定的特殊处理，区别于正常的MOH流程，将会议节点连接到了静默的MOH节点，因此即便是实体类别为server.mixer的通信实体与实体类别为server.ums通信实体之间建立媒体流连接，因为播放的音频是静默的，所以不会影响会议的召开。
图9为如图5所示呼叫保持过程经本发明实施例改进之后的另一种流程示意图。如图9所示：
S901，IP话机B发起MOH业务，向呼叫处理服务器发送携带有SDP的IINVITE消息。该INVITE消息中携带有表示呼叫保持的标记，例如，该INVITE消息的SDP中携带的IP地址为0.0.0.0、或携带的端口号为0。该INVITE消息指明所针对的IP话机A的URI信息、并携带图4中已经建立的会话的呼叫标识符。
S902，呼叫处理服务器向IP话机B回应100 Trying消息。
S903，呼叫处理服务器依据IP话机B所发送的INVITE消息中携带的IP话机A的URI信息，获知IP话机B希望将IP话机A呼叫保持、并向IP话机A发送INVITE消息。该INVITE消息不携带SDP，期望IP话机A返回200 OK消息中给出标记有媒体流连接信息的SDP。
S904，作为会议节点的IP话机A向呼叫处理服务器回应携带有SDP的200 OK消息。也就是说，相比于如图8所示的方式，在本步骤中暂不通过200 OK消息提供实体类别，而是在后续增加的订阅流程中提供实体类别。
S905，呼叫处理服务器发起订阅流程，向作为会议节点的IP话机A发送SUBSCRIBE消息，并在SUBSCRIBE消息的EVENT头域中标注出订阅的是对端的实体类别或者包含实体类别的实体信息，即，EVENT头域的取值可以标注为P-Asserted-Identity-Type或P-Asserted-Identity。
S906，作为会议节点的IP话机A向呼叫处理服务器回应200 OK消息，作为对SUBSCRIBE消息的应答。
S907，作为会议节点的IP话机A向呼叫处理服务器发送NOTIFY消息，并在NOTIFY消息的EVENT头域中标注出携带的是本端实体类别或者实体信息，也就是说，将NOTIFY消息的EVENT头域的取值标注为P-Asserted-Identity-Type、或P-Asserted-Identity。该NOTIFY消息的消息体中还以P-Asserted-Identity-Type的形式、或以包含有Type字段的P-Asserted-Identity的形式给出本端IP话机A的实体类别server.mixer。
经过本步骤，呼叫处理服务器能够获知作为会议节点的IP话机A的实体类别为server.mixer。
S908，呼叫处理服务器向作为会议节点的IP话机A回应200 OK消息，作为对NOTIFY消息的应答。
S909，由于实体类别为server.mixer的通信实体与作为对端通信实体的统一信报服务器的MOH节点连接后会产生影响会议召开的冲突，因此，呼叫处理服务器将本应作为对端通信实体的MOH节点变更为静默MOH节点，然后向静默MOH节点发送携带有SDP的INVITE消息，并在该INVITE消息的P-Asserted-Identity-Type头域中携带IP话机A的实体类别server.mixer、或在P-Asserted-Identity头域的Type字段中携带IP话机A的实体类别server.mixer。该SDP为S904中由IP话机A给出的SDP。
本步骤的处理过程就相当于呼叫处理服务器依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器变更两端通信实体(server类别的会议节点和server类别的MOH节点)中的其中一个用于以播放呼叫保持音乐的方式提供MOH业务的server类别的MOH节点，即，将用于以播放呼叫保持音乐的方式提供MOH业务的server类别的MOH节点，变更为用于以静默播放呼叫保持音乐的方式提供MOH业务的server类别的静默MOH节点。
经过本步骤，静默MOH节点能够获知作为会议节点的IP话机A的实体类别为server.mixer。
S910，静默MOH节点向呼叫处理服务器回应100 Trying消息。
S911，静默MOH节点向呼叫处理服务器发送Session Progress消息。
S912，静默MOH节点向呼叫处理服务器回应携带有SDP的200 OK消息，并在该200 OK消息的P-Asserted-Identity-Type头域中带该静默MOH节点的实体类别server.ums、或在P-Asserted-Identity头域的Type字段中携带该静默MOH节点的实体类别server.ums。
经过本步骤，呼叫处理服务器就能够获知静默MOH节点的实体类别为server.ums。
S913，呼叫处理服务器向静默MOH节点回应ACK消息。
S914，呼叫处理服务器针对在S904中从IP话机A接收到的200 OK消息，向作为会议节点的IP话机A回应携带有SDP的ACK消息，并在该ACK消息的P-Asserted-Identity-Type头域中携带静默MOH节点的实体类别server.ums、或在P-Asserted-Identity头域的Type字段中携带静默MOH节点的实体类别server.ums。该SDP是S912中由静默MOH节点给出的SDP。
S915，作为会议节点的IP话机A与静默MOH节点之间建立媒体流连接。
在本步骤之前，IP话机A和静默MOH节点的用于建立媒体流连接的信息，已按照RFC3261中详细定义的SIP信令的交互规程、以及通信实体之间的会话标记方式，由呼叫处理服务器转发给双方(例如，上述信息可以携带于SDP中)，从而在本步骤中，IP话机A和静默MOH节点能够获知对端的用于建立媒体流连接的信息，因而使本步骤能够在IP话机A与静默MOH节点之间建立媒体流连接。
S916，呼叫处理服务器针对IP话机B在S901发送的INVITE消息，向IP话机B回应携带有SDP的200 OK消息。该SDP中包含呼叫保持的标记，例如IP地址为0.0.0.0或者端口号为0，表示将IP话机B呼叫保持。
S917，IP话机B向呼叫处理服务器回应ACK消息。
至此，作为会议节点的IP话机A与作为普通节点的IP话机B之间的通话变成作为会议节点的IP话机A与静默MOH节点之间的通话，并由静默MOH节点通过媒体流连接向作为会议节点的IP话机A播放静默音，即实质是不向会议节点播放有效音频，避免会议收到保持音乐的影响。也就是说，与如图8所示的流程同理，虽然静默MOH节点的实体类别与MOH节点的实体类别同样为server.ums，但由于此时呼叫处理服务器已根据会议中包含了实体类别为server.mixer的通信实体，而对MOH的业务流程进行了既定的特殊处理；区别于正常的MOH流程，将会议节点连接到了静默的MOH节点，因此即便是在实体类别为server.mixer的通信实体与实体类别为server.ums通信实体之间建立媒体流连接，因为播放的音频是静默的，所以不会影响会议的召开。
上述流程还存在替换方案。例如，假设IP话机A在上述流程开始之前，预先按照与如图3b相同的原理发起订阅流程并获取到静默MOH节点(即将图3b中的IP话机B替换为静默MOH节点)实体类别的订阅流程，则上述流程就无需在S912和S914携带静默MOH节点的实体类别server.ums。再例如，假设呼叫处理服务器在上述流程开始之前，预先按照与如图3b相同的原理发起订阅流程并获取到IP话机A和静默MOH节点(即仅执行图3b中的S333～S336、并将IP话机B分别替换为IP话机A和静默MOH节点)，则上述流程就无需执行S905～S908、也无需在S912和S914携带静默MOH节点的实体类别server.ums。
当然，呼叫处理服务器在上述流程中是针对MOH业务发起订阅流程，但实际应用中，呼叫处理服务器可以针对任意业务发起订阅流程。更优地，为了避免不必要的订阅流程，呼叫处理服务器内部可以设置有订阅策略，只有当前业务属于订阅策略中规定的业务时，呼叫处理服务器才针对当前业务发起订阅流程。
除了利用如图8和图9所示的由呼叫处理服务器依据对实体类别的识别判断当前业务是否可能导致业务冲突、并由呼叫处理服务器在可能导致业务冲突时变更两端通信实体中的其中一个server类别的通信实体(即，变更业务实施方式)的实现方式之外，本实施例还可以由呼叫处理服务器在可能导致业务冲突时禁止与两端通信实体中的其中一个服务器类别的通信实体针对当前业务建立媒体流连接，或者，由两端通信实体中的其中一个server类别的通信实体依据对实体类别的识别判断出当前业务可能导致业务冲突，并由执行判断的server类别的通信实体向对端的通信实体作失败应答，以使得可能导致业务冲突的业务被禁止实施。
图10为如图8所示呼叫保持过程的一种替换方案的流程示意图。如图10所示，
S1001～S1004与如图8所示的S801～S804相同。
S1005，由于实体类别为server.mixer的通信实体与作为对端通信实体的统一信报服务器的MOH节点(呼叫处理服务器中可以预先记录MOH节点的实体类别server.ums)连接后会产生影响会议召开的冲突，因此，呼叫处理服务器禁止IP话机A与MOH节点针对当前MOH业务建立媒体流连接。从而，呼叫处理服务器既不像S805那样做判断、也不向MOH节点发送INIVTE消息，而是直接向IP话机A返回ACK消息，该ACK消息中携带S1001中由IP话机B给出的SDP信息。另外，需注意的是，该SDP中携带有呼叫保持标记(即IP地址为0.0.0.0或者端口号为0)，利用呼叫保持标记能够将作为会议节点的IP话机A呼叫保持。
而且，由于呼叫处理服务器并未与MOH节点进行任何交互，因而即便向IP话机A返回ACK消息，IP话机A也无法与MOH节点建立媒体流连接。
也就是说，本步骤的处理过程就相当于呼叫处理服务器依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器禁止两端通信实体(server类别的会议节点和server类别的MOH节点)中的其中一个server类别的MOH节点针对当前业务建立媒体流连接、以避免业务冲突。
S1006，虽然IP话机A无法与MOH节点建立媒体流连接，但呼叫处理服务器针对IP话机B在S1001发送的INVITE消息，仍然向IP话机B回应携带有SDP的200 OK消息。即便如此，IP话机B与作为会议节点的IP话机A之间仍有会话存在，但是因为IP话机A已进入呼叫保持状态，因而双方并没有实际存在的音频交互。
S1007，IP话机B向呼叫处理服务器回应ACK消息。
至此，作为会议节点的IP话机A与MOH节点之间的通话被禁止，从而避免了会议收到保持音乐的影响，进而不会影响会议的召开。
前文已述，图4至图7是一个有通知呼叫转移的业务流程，经过图10作为对图8流程的一个替换方案(进而相当于对图5流程的一个替换方案)，原有的图6和图7流程仍可继续，完成原有的有通知呼叫转移的业务流程。
图11为如图8所示呼叫保持过程的另一种替换方案的流程示意图。如图11所示：
S1101～S1104与如图8所示的S801～S804相同。
S1105，呼叫处理服务器不像S805那样作判断，而是向MOH节点发送携带有SDP的INVITE消息、并在该INVITE消息的P-Asserted-Identity-Type头域中携带IP话机A的实体类别server.mixer、或在P-Asserted-Identity头域的Type字段中携带IP话机A的实体类别server.mixer。
S1106，MOH节点获知对端的实体类型为server.mixer，判断出本节点与对端连接后会产生影响会议召开的冲突，因此，MOH节点向呼叫处理服务器返回480消息，拒绝对端的实体类别为server.mixer的IP话机A与其建立媒体流连接。
本步骤的处理过程就相当于通信实体依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器禁止与对端针对当前业务建立媒体流连接、以避免业务冲突。
S1107，呼叫处理服务器向MOH节点回应ACK消息。
S1108，呼叫处理服务器先针对IP话机A在S1104所发送的200 OK消息，向IP话机A返回携带SDP的ACK消息。该SDP是S1101中由IP话机B给出的SDP，该SDP中包含的呼叫保持的标记(即IP地址为0.0.0.0或者端口为0)，利用呼叫保持标记能够将作为会议节点的IP话机A呼叫保持。
而且，由于MOH节点已拒绝建立媒体流连接，因而即便向IP话机A返回ACK消息，IP话机A也无法与MOH节点建立媒体流连接。
S1109，虽然IP话机A无法与MOH节点建立媒体流连接，但呼叫处理服务器针对IP话机B在S1101发送的INVITE消息，仍然向IP话机B回应携带有SDP的200 OK消息。即便如此，IP话机B与作为会议节点的IP话机A之间仍有会话存在，但是因为IP话机A已进入呼叫保持状态，因而双方并没有实际存在的音频交互。
S1110，IP话机B向呼叫处理服务器回应ACK消息。
至此，作为会议节点的IP话机A与MOH节点之间的通话被MOH节点拒绝，从而避免了会议收到保持音乐的影响，进而不会影响会议的召开。
前文已述，图4至图7是一个有通知呼叫转移的业务流程，经过图11作为对图8流程的一个替换方案(进而相当于对图5流程的一个替换方案)，原有的图6和图7流程仍可继续，完成原有的有通知呼叫转移的业务流程。
图12为如图9所示呼叫保持过程的一种替换方案的流程示意图。如图12所示：
S1201～S1208与如图9所示的S901～S908相同。
S1209，由于实体类别为server.mixer的通信实体与作为对端通信实体的统一信报服务器的MOH节点(呼叫处理服务器中可以预先记录MOH节点的实体类别server.ums)连接后会产生影响会议召开的冲突，因此，呼叫处理服务器禁止IP话机A与MOH节点针对当前MOH业务建立媒体流连接。从而，呼叫处理服务器既不像S909那样做判断、也不向MOH节点发送INIVTE消息，而是直接向IP话机A返回ACK消息。该SDP是S1201中由IP话机B给出的SDP，该SDP中包含呼叫保持的标记(即IP地址为0.0.0.0或者端口为0)，利用该呼叫保持标记能够将作为会议节点的IP话机A呼叫保持。
而且，由于呼叫处理服务器并未与MOH节点进行任何交互，因而即便向IP话机A返回ACK消息，IP话机A也无法与MOH节点建立媒体流连接。
本步骤的处理过程就相当于呼叫处理服务器依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器禁止与两端通信实体(server类别的会议节点和server类别的MOH节点)中的其中一个server类别的MOH节点针对当前业务建立媒体流连接、以避免业务冲突。
S1210，虽然IP话机A无法与MOH节点建立媒体流连接，但呼叫处理服务器针对IP话机B在S1201发送的INVITE消息，仍然向IP话机B回应携带有SDP的200 OK消息。即便如此，IP话机B与作为会议节点的IP话机A之间仍有会话存在，但是因为IP话机A已进入呼叫保持状态，因而双方并没有实际存在的音频交互。
S1211，IP话机B向呼叫处理服务器回应ACK消息。
至此，作为会议节点的IP话机A与MOH节点之间的通话被禁止，从而避免了会议收到保持音乐的影响，进而不会影响会议的召开。
前文已述，图4至图7是一个有通知呼叫转移的业务流程，经过图12作为对图9流程的一个替换方案(进而相当于对图5流程的一个替换方案)，原有的图6和图7流程仍可继续，完成原有的有通知呼叫转移的业务流程。
图13为如图9所示呼叫保持过程的另一替换方案的流程示意图。如图13所示：
S1301～S1308与如图9所示的S901～S908相同。
S1309，呼叫处理服务器不像S909那样作判断，而是向MOH节点发送携带有SDP的INVITE消息、并在该INVITE消息的P-Asserted-Identity-Type头域中携带IP话机A的实体类别server.mixer、或在P-Asserted-Identity头域的Type字段中携带IP话机A的实体类别server.mixer。
S1310，MOH获知对端通信实体类别为server.mixe，判断出本节点与对端通信实体连接后会产生影响会议召开的冲突，因此，MOH节点向呼叫处理服务器返回480消息，拒绝对端的实体类别为server.mixer的IP话机A与其建立媒体流连接。
本步骤的处理过程就相当于通信实体依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器禁止与对端针对当前业务建立媒体流连接、以避免业务冲突。
S1311，呼叫处理服务器向MOH节点回应ACK消息。
S1312，呼叫处理服务器先针对IP话机A在S1304所发送的200 OK消息，向IP话机A返回携带SDP的ACK消息。该SDP是S1201中由IP话机B给出的SDP，该SDP中包含呼叫保持的标记(即IP地址为0.0.0.0或者端口为0)，利用该呼叫保持标记能够将作为会议节点的IP话机A呼叫保持。
而且，由于MOH节点已拒绝建立媒体流连接，因而即便向IP话机A返回ACK消息，IP话机A也无法与MOH节点建立媒体流连接。
S1313，虽然IP话机A无法与MOH节点建立媒体流连接，但呼叫处理服务器针对IP话机B在S1301发送的INVITE消息，仍然向IP话机B回应携带有SDP的200 OK消息。即便如此，IP话机B与作为会议节点的IP话机A之间仍有会话存在，但是因为IP话机A已进入呼叫保持状态，因而双方并没有实际存在的音频交互。
S1314，IP话机B向呼叫处理服务器回应ACK消息。
至此，作为会议节点的IP话机A与MOH节点之间的通话被MOH节点拒绝，从而避免了会议收到保持音乐的影响，进而不会影响会议的召开。
前文已述，图4至图7是一个有通知呼叫转移的业务流程，经过图13作为对图9流程的一个替换方案(进而相当于对图5流程的一个替换方案)，原有的图6和图7流程仍可继续，完成原有的有通知呼叫转移的业务流程。
上述的实例仅仅是解决具有混音特性的通信实体与MOH业务之间冲突的一种具体应用，实际应用中还可能存在其他应用。例如，当任一IP话机请求修改与对端通信实体之间的媒体流连接的属性时，对端通信实体可以依据已识别出的两端通信实体的实体类别是否会导致属性修改后产生冲突而拒绝该请求，当然，也可以由呼叫处理服务器拒绝属性修改后的对应业务、或对属性修改后的对应业务采用特殊处理、或变更对端通信实体等等。
也就是说，本发明实施例中主要关注的是如何定义实体类别、如何在SIP信令中携带实体类别、如何获取对端的实体类别，以使得SIP会话两端通信实体能够彼此相互识别对端以及使呼叫处理服务器能够识别SIP会话两端通信实体的实体类别，并据此对实施的通信业务进行适当动作；而对于本发明实施例所能够适用的所有应用场景，本文不再一一列举。
此外，本发明实施例中还提供了可实现实体类别识别的一种统一通信***，其至少包括呼叫处理服务器，以及，除呼叫处理服务器之外的例如IP话机、PC终端、统一信报服务器等可能存在的若干通信实体。
其中，呼叫处理服务器和/或任意通信实体接收当前业务对应的其他通信实体发送的携带有实体类别的SIP信令；以及，呼叫处理服务器或该任意通信实体(该任意通信实体为server类别时)依据对实体类别的识别使业务有选择性地被实施、以避免业务冲突。
本发明实施例中还提供了一种呼叫处理服务器，其包括信令接收模块和策略执行模块。其中，信令接收模块，接收当前业务对应的任意通信实体发送的携带有实体类别的SIP信令(实体类别的格式以及携带方式如前文所述)；而策略执行模块则用于依据对实体类别的识别使业务有选择性地被实施(可参照前文所述的由呼叫处理服务器使业务有选择性地被实施的具体实现)、以避免业务冲突。
可选地，呼叫处理服务器可以进一步包括信令发送模块，用于将信令接收模块所接收到的任意通信实体的实体类别携带于SIP信令中发送给该任意通信实体的对端通信实体。而且，如前文所述，除了由呼叫处理服务器使业务有选择性地被实施之外，还可以由通信实体(该任意通信实体为server类别时)来使业务有选择性地被实施，因此，呼叫处理服务器还可以进一步包括执行控制模块，用于在信令接收模块接收到任意通信实体的实体类别后，选择触发策略执行模块和信令发送模块中的一个，当策略执行模块被触发时即由呼叫处理服务器使业务有选择性地被实施，而当信令发送模块被触发时，则可能是由接收到信令发送模块的SIP信令的通信实体(该任意通信实体为server类别时)来使业务有选择性地被实施。
另需要补充说明的是，虽然本实施例中利用通信实体或呼叫处理服务器对实体类别的识别可用于选择性地执行业务，但实际应用中，也可以利用实体类别来实现统一通信***中的其他控制功能。
以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换以及改进等，均应包含在本发明的保护范围之内。
Claims (34)
1.一种业务控制方法，其特征在于，包括如下步骤：
呼叫处理服务器和/或任意通信实体接收当前业务对应的其他通信实体发送的携带有实体类别的SIP信令；
以及，由呼叫处理服务器依据对SIP会话两端的实体类别的识别对当前SIP会话是否与实现某种业务而发起的流程出现冲突作出判断、并决定是否实施或者如何实施，或者由该任意通信实体依据对本端和对端的实体类别的识别对当前SIP会话是否存在冲突作出判断、并决定向对端作出成功或者失败应答，以使业务有选择性地被实施、以避免当前业务的冲突；
其中，实体类别至少包括第一级实体类别和第二级实体类别，第二级实体类别为第一级实体类别的子类别。
2.如权利要求1所述的业务控制方法，其特征在于，该业务控制方法通过业务发起流程使呼叫处理服务器被动地接收携带有实体类别的SIP信令、或者使呼叫处理服务器和通信实体被动地接收携带有实体类别的SIP信令。
3.如权利要求2所述的业务控制方法，其特征在于，业务发起流程中所使用的携带实体类别的SIP信令包括下述之一或任意组合：INVITE消息、200OK消息、以及ACK消息；
该业务控制方法预先在INVITE消息、200OK消息、ACK消息中定义出用于表示实体类别的P-Asserted-Identity-Type头域，并在INVITE消息、200OK消息、ACK消息的P-Asserted-Identity-Type头域中携带实体类别；
或者，该业务控制方法预先在INVITE消息、200OK消息、ACK消息的P-Asserted-Identity头域中定义出用于表示实体类别的一Type字段，并在INVITE消息、200OK消息、ACK消息的P-Asserted-Identity头域的该Type字段中携带实体类别。
4.如权利要求1所述的业务控制方法，其特征在于，该业务控制方法通过订阅流程使呼叫处理服务器和/或通信实体主动要求获取携带有实体类别的SIP信令。
5.如权利要求4所述的业务控制方法，其特征在于，订阅流程中使用SUBSCRIBE消息主动要求获取携带于SIP信令的实体类别，并使用NOTIFY消息携带实体类别；
该业务控制方法预先在SUBSCRIBE消息和NOTIFY消息中定义出用于表示实体类别的P-Asserted-Identity-Type头域，在SUBSCRIBE消息和NOTIFY消息用于订阅实体类别时，SUBSCRIBE消息和NOTIFY消息的EVENT头域中标记出P-Asserted-Identity-Type头域、NOTIFY消息的消息体中还包括携带实体类别的P-Asserted-Identify-Type头域；
或者，该业务控制方法预先在SUBSCRIBE消息和NOTIFY消息的P-Asserted-Identity头域中定义出用于表示实体类别的一Type字段，在SUBSCRIBE消息和NOTIFY消息用于订阅实体类别时，SUBSCRIBE消息和NOTIFY消息的EVENT头域中标记出P-Asserted-Identify头域、NOTIFY消息的消息体中还包括所述Type字段携带实体类别的P-Asserted-Identify头域。
6.如权利要求1至5中任一项所述的业务控制方法，其特征在于，所述第一级实体类别至少包括：用户代理类别、以及用于提供业务的服务器类别。
7.如权利要求6所述的业务控制方法，其特征在于，该业务控制方法由呼叫处理服务器依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器变更两端通信实体中的其中一个服务器类别的通信实体、以避免业务冲突。
8.如权利要求7所述的业务控制方法，其特征在于，所述当前业务为MOH业务；所述通信实体包括：服务器类别的会议节点、被变更的用于以播放呼叫保持音乐的方式提供MOH业务的服务器类别的MOH节点、以及变更后的用于以静默播放呼叫保持音乐的方式提供MOH业务的服务器类别的静默MOH节点。
9.如权利要求6所述的业务控制方法，其特征在于，该业务控制方法由呼叫处理服务器依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器禁止与两端通信实体中的其中一个服务器类别的通信实体针对当前业务建立媒体流连接、以避免业务冲突。
10.如权利要求9所述的业务控制方法，其特征在于，所述当前业务为MOH业务；所述通信实体包括：服务器类别的会议节点、以及被禁止的用于以播放呼叫保持音乐的方式提供MOH业务的服务器类别的MOH节点。
11.如权利要求6所述的业务控制方法，其特征在于，该业务控制方法由两端通信实体中的其中一个服务器类别的通信实体依据对实体类别的识别判断出当前业务可能导致业务冲突，并由执行所述判断的服务器类别的通信实体向对端的通信实体作失败应答，以使得可能导致业务冲突的业务被禁止实施。
12.如权利要求11所述的业务控制方法，其特征在于，所述当前业务为MOH业务；所述通信实体包括：服务器类别的会议节点、以及执行所述判断的用于以播放呼叫保持音乐的方式提供MOH业务的服务器类别的MOH节点。
13.一种统一通信***，其特征在于，至少包括呼叫处理服务器、以及除所述呼叫处理服务器之外的其他若干通信实体，其中，
呼叫处理服务器和/或任意通信实体接收当前业务对应的其他通信实体发送的携带有实体类别的SIP信令；
以及，呼叫处理服务器依据对SIP会话两端的实体类别的识别当前SIP会话是否与实现某种业务而发起的流程出现冲突作出判断、并决定是否实施或者如何实施、或者该任意通信实体依据对本端和对端的实体类别的识别对当前SIP会话是否存在冲突作出判断、并决定向对端作出成功或者失败应答，以使业务有选择性地被实施、以避免业务冲突；
其中，实体类别至少包括第一级实体类别和第二级实体类别，第二级实体类别为第一级实体类别的子类别。
14.如权利要求13所述的统一通信***，其特征在于，呼叫处理服务器在业务发起流程中被动地接收携带有实体类别的SIP信令，或者，呼叫处理服务器和通信实体在业务发起流程中被动地接收携带有实体类别的SIP信令。
15.如权利要求14所述的统一通信***，其特征在于，业务发起流程中所使用的携带实体类别的SIP信令包括下述之一或任意合：INVITE消息、200OK消息、以及ACK消息；
该统一通信***中预先在INVITE消息、200OK消息、ACK消息中定义有用于表示实体类别的P-Asserted-Identity-Type头域，并在INVITE消息、200OK消息、ACK消息的P-Asserted-Identity-Type头域中携带实体类别；
或者，该统一通信***中预先在INVITE消息、200OK消息、ACK消息的P-Asserted-Identity头域中定义出用于表示实体类别的一Type字段，并在INVITE消息、200OK消息、ACK消息的P-Asserted-Identity头域的该Type字段中携带实体类别。
16.如权利要求13所述的统一通信***，其特征在于，呼叫处理服务器和/或通信实体通过订阅流程主动要求获取携带有实体类别的SIP信令。
17.如权利要求16所述的统一通信***，其特征在于，订阅流程中使用SUBSCRIBE消息主动要求获取携带于SIP信令的实体类别，并使用NOTIFY消息携带实体类别；
该统一通信***预先在SUBSCRIBE消息和NOTIFY消息中定义有用于表示实体类别的P-Asserted-Identity-Type头域，在SUBSCRIBE消息和NOTIFY消息用于订阅实体类别时，SUBSCRIBE消息和NOTIFY消息的EVENT头域中标记出P-Asserted-Identity-Type头域、NOTIFY消息的消息体中还包括携带实体类别的P-Asserted-Identify-Type头域；
或者，该统一通信***中预先在SUBSCRIBE消息和NOTIFY消息的P-Asserted-Identity头域中定义出用于表示实体类别的一Type字段，在SUBSCRIBE消息和NOTIFY消息用于订阅实体类别时，SUBSCRIBE消息和NOTIFY消息的的EVENT头域中标记出P-Asserted-Identify头域、NOTIFY消息的消息体中还包括所述Type字段携带实体类别的P-Asserted-Identify头域。
18.如权利要求13至17中任一项所述的统一通信***，其特征在于，所述第一级实体类别至少包括：用户代理类别、以及用于提供业务的服务器类别。
19.如权利要求18所述的统一通信***，其特征在于，该统一通信***中由呼叫处理服务器依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器变更两端通信实体中的其中一个服务器类别的通信实体、以避免业务冲突。
20.如权利要求19所述的统一通信***，其特征在于，所述当前业务为MOH业务；所述通信实体包括：服务器类别的会议节点、被变更的用于以播放呼叫保持音乐的方式提供MOH业务的服务器类别的MOH节点、以及变更后的用于以静默播放呼叫保持音乐的方式提供MOH业务的服务器类别的静默MOH节点。
21.如权利要求18所述的统一通信***，其特征在于，该统一通信***中由呼叫处理服务器依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器禁止与两端通信实体中的其中一个服务器类别的通信实体针对当前业务建立媒体流连接、以避免业务冲突。
22.如权利要求21所述的统一通信***，其特征在于，所述当前业务为MOH业务；所述通信实体包括：服务器类别的会议节点、以及被禁止的用于以播放呼叫保持音乐的方式提供MOH业务的服务器类别的MOH节点。
23.如权利要求18所述的统一通信***，其特征在于，该统一通信***中由两端通信实体中的其中一个服务器类别的通信实体依据对实体类别的识别判断出当前业务可能导致业务冲突，并由执行所述判断的服务器类别的通信实体向对端的通信实体作失败应答，以使得可能导致业务冲突的业务被禁止实施。
24.如权利要求23所述的统一通信***，其特征在于，所述当前业务为MOH业务；所述通信实体包括：服务器类别的会议节点、以及执行所述判断的用于以播放呼叫保持音乐的方式提供MOH业务的服务器类别的MOH节点。
25.一种呼叫处理服务器，其特征在于，包括：
信令接收模块，接收当前业务对应的任意通信实体发送的携带有实体类别的SIP信令；
策略执行模块，依据对SIP会话两端的实体类别的识别使业务有选择性地被实施、以避免业务冲突；
其中，实体类别至少包括第一级实体类别和第二级实体类别，第二级实体类别为第一级实体类别的子类别。
26.如权利要求25所述的呼叫处理服务器，其特征在于，所述信令接收模块在业务发起流程中被动地接收携带于SIP信令的实体类别。
27.如权利要求26所述的呼叫处理服务器，其特征在于，业务发起流程中所使用的携带实体类别的SIP信令包括下述之一或任意组合：INVITE消息、200OK消息、以及ACK消息；
INVITE消息、200OK消息、ACK消息中预先定义有用于携带实体类别的P-Asserted-Identity-Type头域；
或者，INVITE消息、200OK消息、ACK消息的P-Asserted-Identity头域中预先定义有用于携带实体类别的一Type字段。
28.如权利要求25所述的呼叫处理服务器，其特征在于，所述信令接收模块在订阅流程中主动要求获取携带有实体类别的SIP信令。
29.如权利要求28所述的呼叫处理服务器，其特征在于，订阅流程中使用SUBSCRIBE消息主动要求获取携带于SIP信令的实体类别，并使用NOTIFY消息携带实体类别；
SUBSCRIBE消息和NOTIFY消息中预先定义有用于表示实体类别的P-Asserted-Identity-Type头域，在SUBSCRIBE消息和NOTIFY消息用于订阅实体类别时，SUBSCRIBE消息和NOTIFY消息的EVENT头域中标记出P-Asserted-Identity-Type头域、NOTIFY消息的消息体中包括携带实体类别的P-Asserted-Identify-Type头域；
或者，SUBSCRIBE消息和NOTIFY消息的P-Asserted-Identity头域中预先定义有用于表示实体类别的一Type字段，在SUBSCRIBE消息和NOTIFY消息用于订阅实体类别时，SUBSCRIBE消息和NOTIFY消息的EVENT头域中标记出P-Asserted-Identify头域、NOTIFY消息的消息体中还包括所述Type字段携带实体类别的P-Asserted-Identify头域。
30.如权利要求25至29中任一项所述的呼叫处理服务器，其特征在于，所述第一级实体类别至少包括：用户代理类别、以及用于提供业务的服务器类别。
31.如权利要求30所述的呼叫处理服务器，其特征在于，所述策略执行模块依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器变更两端通信实体中的其中一个服务器类别的通信实体、以避免业务冲突。
32.如权利要求31所述的呼叫处理服务器，其特征在于，所述当前业务为MOH业务；所述通信实体包括：服务器类别的会议节点、被变更的用于以播放呼叫保持音乐的方式提供MOH业务的服务器类别的MOH节点、以及变更后的用于以静默播放呼叫保持音乐的方式提供MOH业务的服务器类别的静默MOH节点。
33.如权利要求30所述的呼叫处理服务器，其特征在于，所述策略执行模块依据对实体类别的识别判断当前业务是否可能导致业务冲突，在可能导致业务冲突时由呼叫处理服务器禁止与两端通信实体中的其中一个服务器类别的通信实体针对当前业务建立媒体流连接、以避免业务冲突。
34.如权利要求33所述的呼叫处理服务器，其特征在于，所述当前业务为MOH业务；所述通信实体包括：服务器类别的会议节点、以及被禁止的用于以播放呼叫保持音乐的方式提供MOH业务的服务器类别的MOH节点。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201110062032.0A CN102104608B (zh) | 2011-03-15 | 2011-03-15 | 业务控制方法以及统一通信***和呼叫处理服务器 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201110062032.0A CN102104608B (zh) | 2011-03-15 | 2011-03-15 | 业务控制方法以及统一通信***和呼叫处理服务器 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN102104608A CN102104608A (zh) | 2011-06-22 |
| CN102104608B true CN102104608B (zh) | 2014-06-04 |
Family
ID=44157134
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201110062032.0A Active CN102104608B (zh) | 2011-03-15 | 2011-03-15 | 业务控制方法以及统一通信***和呼叫处理服务器 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102104608B (zh) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109495709B (zh) * | 2018-10-16 | 2020-05-26 | 视联动力信息技术股份有限公司 | 一种视联网管理***和方法 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1863209A (zh) * | 2006-02-10 | 2006-11-15 | 华为技术有限公司 | 一种ims业务触发方法以及ims网络 |
| CN1925522A (zh) * | 2005-09-02 | 2007-03-07 | 华为技术有限公司 | 在呼叫中传递用户类别信息的方法 |
-
2011
- 2011-03-15 CN CN201110062032.0A patent/CN102104608B/zh active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1925522A (zh) * | 2005-09-02 | 2007-03-07 | 华为技术有限公司 | 在呼叫中传递用户类别信息的方法 |
| CN1863209A (zh) * | 2006-02-10 | 2006-11-15 | 华为技术有限公司 | 一种ims业务触发方法以及ims网络 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN102104608A (zh) | 2011-06-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7805532B2 (en) | Platform for interoperability | |
| US8327024B2 (en) | System and method for SMS/IP interoperability | |
| JP4560018B2 (ja) | 接続制御システム、接続制御装置、接続制御方法および接続制御プログラム | |
| CN101277342B (zh) | 一种实现分叉业务的方法、装置及*** | |
| US20080281971A1 (en) | Network multimedia communication using multiple devices | |
| JP5274668B2 (ja) | 統合ｉｐメッセージングサービスにおけるインターワーキングのためのセッションを制御する方法及び装置とそのシステム | |
| EP2585939B1 (en) | Dynamic federations | |
| CN101515949A (zh) | 便于用户设备间会话转移的方法和*** | |
| KR20080102242A (ko) | 통화 연결음을 사용하여 존재 정보를 제공하는 방법 및 시스템 | |
| CN106797379B (zh) | 使用合成标识符的电话会议*** | |
| CN1984135A (zh) | 一种进行会话能力信息操作的方法及网络实体 | |
| CN105706410A (zh) | 用于交换服务能力的方法和用户设备 | |
| CN106664287A (zh) | 用于控制多媒体通信网络中的通信会话建立的方法和通信处理设备 | |
| CN102291415B (zh) | 媒体流处理方法、***及家庭网关 | |
| CN1984132B (zh) | 一种对会话能力信息进行处理的方法和终端 | |
| WO2011029335A1 (zh) | 一种sip会话的路由***及方法 | |
| US7620167B2 (en) | Apparatus to override the redirect or reject feature at an SIP end point | |
| WO2008006311A1 (fr) | Procédé et dispositif d'utilisation d'un identificateur de terminal utilisateur | |
| CN106161357B (zh) | Ims网络中实现合法监听的方法、装置及应用服务器 | |
| CN101184129A (zh) | 实现转移呼叫的方法、装置及*** | |
| CN101072261A (zh) | 实现转移呼叫的方法、装置及*** | |
| CN101388883B (zh) | 多媒体会话中特定设备的管理方法、***和设备 | |
| CN102104608B (zh) | 业务控制方法以及统一通信***和呼叫处理服务器 | |
| JP2019518382A (ja) | 複数のネットワークタイプを通じて通信するためのシステムおよび方法 | |
| JP5031766B2 (ja) | Ｉｐ電話サービスの相互接続 |
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 | ||
| CP03 | Change of name, title or address |
Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Patentee after: NEW H3C TECHNOLOGIES Co.,Ltd. Address before: 310053 Hangzhou hi tech Industrial Development Zone, Zhejiang province science and Technology Industrial Park, No. 310 and No. six road, HUAWEI, Hangzhou production base Patentee before: HANGZHOU H3C TECHNOLOGIES Co.,Ltd. |
|
| CP03 | Change of name, title or address | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20230620 Address after: 310052 11th Floor, 466 Changhe Road, Binjiang District, Hangzhou City, Zhejiang Province Patentee after: H3C INFORMATION TECHNOLOGY Co.,Ltd. Address before: 310052 Changhe Road, Binjiang District, Hangzhou, Zhejiang Province, No. 466 Patentee before: NEW H3C TECHNOLOGIES Co.,Ltd. |
|
| TR01 | Transfer of patent right |