[LCS]LCS2005服务器应用程序

摘要： LCS2005 服务器应用程序可以通过基于 .NET Framework 的服务器API 对SIP 协议栈进行底层访问，使用这些API 开发的 服务器应用程序能够实现诸如自定义消息筛选、基于规则的路由和消息记录之类的功能。本文档将从LCS服务器角色、LCS与SIP协议以及为企业设计的体系架构三方面阐述LCS服务器应用程序的功能及开发。

 

第一篇  LCS 服务器角色

 

服务器应用程序可以部署在 Live Communications Server 2005 支持的任何或全部服务器角色上。了解每个新服务器角色的作用及其在SIP 通信流中的位置 对于应用程序的设计和部署都是非常重要的。下面首先了解一下服务器角色的作用及架构。

 

一、 关于每个服务器角色的作用：

Live Communications Server 体系结构由多个角色构成，每个角色提供一种不同的功能。您的环境必须包括前两种角色之一：Standard Edition 或 Enterprise Edition 。它们用于处理 Live Communications Server 的前端操作。这两种角色在 Live Communications Server 体系结构内充当“主服务器”。所有其他角色都与这两种前端体系结构组件协同工作。

１、Standard Edition

Live Communications Server 2005 Standard Edition 为较小的、不太复杂的网络提供了一种使用状态服务和 IM 服务的简便方法。Standard Edition 是一个完全独立自足的组件，不需要在外部运行 SQL Server 。

 

２、Enterprise Edition

对于需要更高可用性或更大可伸缩性的部署，“主服务器”的概念被分成了两个不同的部分：Live Communications Server Enterprise Edition ，用于管理客户端连接、状态和其他实时通信功能（如即时消息）；Live Communications Server 2005, 后端数据库，一种运行 Microsoft SQL Server ™ 2000 SP3a 的后端服务器，可以组成群集。Enterprise Edition Server 与后端数据库一起构成了池。

什么是池？

Live Communications Server 2005, 企业版池是一系列连接到中央 Live Communications Server 2005, 后端数据库的 Enterprise Edition Server 。

用户（客户端）在企业版池上进行注册。硬件负载平衡器将用户定向到池中特定的服务器，该负载平衡器负责向池中的服务器分配负载。负载平衡器公开一个 VIP 地址（虚拟 Internet 协议地址）供客户端用来访问池。池中的各台运行 Live Communications Server 2005 Enterprise Edition 的服务器均负责连接处理、安全性和身份验证、协议处理以及服务器应用程序。诸如联系人列表和 ACL （访问控制列表）之类的静态数据作为永久性数据存储在 Live Communications Server 2005, 后端数据库上。客户端可在某个时刻注册到一台服务器上，而在另一个时刻注册到另外一台服务器上；或者，客户端可以具有多台用户登录到的设备（终结点）— 用户在同一时刻通过不同的服务器登录到每台设备。

用户数据驻留在 Live Communications Server 2005, 后端数据库（它是一台运行 SQL Server 2000 的服务器）上。该数据库包含记录，这些记录中保存着上文讨论的静态数据和动态用户数据（例如终结点及用户的当前描述）；该数据库还运行着一组存储过程调用，这些存储过程调用构成了运行的软件的核心。池中的 Live Communications Server 通过高速网络与后端服务器相连接。这些 Live Communications Server 还运行 UR （用户复制程序）软件来提供与 Active Directory 的连接，以便在 Live Communications Server 2005, 后端数据库和 Active Directory 之间同步用户帐户信息。

３、Director

Director 是 Standard Edition Server 或 Enterprise Edition Server 的一种特殊配置模式，该模式不用于承载任何用户。Director 用于对远程客户端（企业拥有使用访问代理服务器从防火墙外部进行连接的用户）进行验证和授权，并用于将客户端路由到它们的主服务器。根据设计，访问代理服务器不与 Active Directory 进行通信，因此它们只验证用户的身份。

４、访问代理服务器

访问代理服务器支持联盟（即与其他组织中的用户进行通信的能力）或远程用户访问（即用户从外部位置连接到内部 Live Communications Server 的能力）。访问代理服务器是一种经过特殊配置的代理服务器，它专用于在外围网络运行并已通过测试。访问代理服务器采用了将网络的外部边缘同内部边缘分开的受限路由规则，并提供了一个中央平台来管理和启用跨组织的基于域的策略。访问代理服务器不需要 Active Directory ，因为它只管理 SIP 域，不管理用户。虽然为 Standard Edition 和 Enterprise Edition 安装都提供了访问代理服务器角色，但访问代理服务器需要 Standard Edition 许可证。

５、代理服务器

Live Communications Server 2005, 代理服务器提供了一个用于自定义部署和应用程序开发的平台。可以配置静态路由规则，同时还可以使用 MSPL （Microsoft SIP 处理语言）或托管代码（例如 C++ 、C# ）编写更加复杂的路由应用程序。虽然为 Standard Edition 和 Enterprise Edition 安装都提供了代理服务器角色，但代理服务器需要 Standard Edition 许可证。

６、存档服务

存档服务系统由一台服务器组成，该服务器包含配置了存档功能的用户的存档即时消息会话。每个承载要存档的用户的 Live Communications Server 上都必须启用存档。存档服务使用 SQL 数据库来存储存档信息。利用存档服务，公司便可以实施那些要求保留即时消息通信的企业或政府策略。

 

二、服务体系架构

Standard Edition 和 Enterprise Edition Server 共享一个建立在 Winsock （标准 Windows 网络编程接口）之上的公用分层体系结构。下图显示了组成 Live Communications Server 2005 服务器的不同层和组件。

 

图 1    Live Communications Server 2005 层和组件

 

 

 

SIP 代理服务器。SIP 代理服务器（也称为协议栈或 SIP 栈）是构建所有其他服务的核心协议平台。它提供了基本的网络和安全结构，负责执行连接管理、消息头分析、路由、身份验证和状态管理等任务。

用户服务模块。 用户服务模块是 SIP 注册器和状态代理服务器 。它提供了构建于 SIP 代理服务器之上的高度集成的 IM 和状态功能，并使用 SQL Server 实现高性能数据访问 。用户服务需要的配置和安全信息来自 Active Directory 。

服务器 API 模块。 服务器 API 模块为脚本自定义消息筛选器和路由应用程序提供了基本的脚本功能 。脚本既可以在进程中运行，也可以根据需要发送到在单独的进程中运行的托管代码应用程序。

内容记录 。内容记录模块使记录通过服务器传递的即时消息成为可能。

 

 

第二篇  LCS 与SIP

 

与 HTTP 一样，SIP 也是一种请求- 响应协议。SIP 客户端是一个代表启用了 SIP 的用户生成请求的实体（例如 Windows Messenger 5.1 ）。SIP 服务器（例如 Live Communications Server 2005 ）接收请求并生成响应。

一、SIP 请求：

Live Communications Server 2005 中使用的 SIP 请求包括但不限于以下各项：

l         INVITE ：邀请用户加入 SIP 会话。

l         ACK ：确认收到对 INVITE 请求的最终响应。

l         CANCEL ：只要 ACK 请求尚未发出，即可取消挂起的 INVITE 。

l         BYE ：发信号请求终止会话。

l         REGISTER ：告知 SIP 服务器用户已登录或已移动到新位置。

l         OPTION ：查询服务器的功能。

l         NOTIFY ：发送关于发生了特定事件的通知。

l         SUBSCRIBE ：请求特定用户信息的通知，例如状态、最后联系人和 ACL （访问控制列表）。

l         SERVICE ：轮询和请求状态更新并修改联系人列表和 ACL 。

 

二、SIP 响应类：

范围	响应类
100 – 199	信息
200 – 299	成功
300 – 399	重定向
400 – 499	客户端错误
500 – 599	服务器错误
600 – 699	全局失败

 

每个响应类包含多个状态代码（仅以两个代码为例：401 “未经授权”或 414 “请求 URI 过大”。）

SIP 请求包括一个请求行、若干个标头和消息正文。请求行包含请求 URI （下一个跃点的地址）和正在使用的协议版本。

SIP 响应在结构上与 SIP 请求相似，但它以状态行而不是请求行开头。状态行包括协议版本、状态代码和描述状态的文本短语。

 

      

 

三、SIP 标头（注： API 增强功能中的“应用程序通信”就是通过添加标头实现的，后详 ）

SIP 标头传递有关请求或响应的信息，在某些情况下，还传递有关消息正文的信息。Live Communications Server SIP 代理服务器将检查消息头以确定如何处理和路由消息。

Live Communications Server 2005 通常使用下列 SIP 标头：

l         To 。 某个请求的预期接收者的标识。它采用 SIP URL 的格式，其前缀为“Sip:” ，后跟一个“user@domain” 格式的字符串。与请求 URI 不同，To 标头中的 URL 无法改变，而请求 URI 是下一个跃点的地址，可能根据处理消息的每台服务器而改变。

l         From 。 发送消息的用户标识。

l         Call-ID 。 特定 SIP 邀请的唯一标识符。

l         Contact 。 与用户驻留的 SIP 服务器的地址相对应的用户地址。重定向消息的服务器可以将预期接收者的地址写在响应客户端时返回的 Contact 标头中。然后客户端不必通过服务器就可以直接联系接收者。

l         Record-Route 。 代理消息的服务器可将自己的 URI 添加到 Record Route 标头中，以表明它希望保留在当前会话中所有后续 SIP 通信的传输路径中。例如，为了安全起见，Live Communications Server 2005, 代理服务器将它的 Record-Route 标头插入到所有来自公司分支机构的通信中，以确保所有对这些通信的响应在通过分支机构的防火墙之前都必须通过该服务器返回。

l         Route 。 某个请求的路径中所有实体的 SIP-URI 列表。收到消息后，每个 Live Communications Server 都立即删除标识自己的 Route 标头，并将消息转发到列表中的下一个 URI （如果有的话）。

l         Via 。 处理了请求的所有 Live Communications Server 的地址。Via 标头用于将响应定位回客户端，使用的路径与发送响应时相同（但方向相反）。服务器也可通过检查 Via 标头来确定以前是否处理过请求。

 

在 Live Communications Server 2005 SIP 网络中，请求被路由到代表启用了 SIP 的 Windows 用户帐户的终结点。如果 Active Directory 中没有 URI 的用户帐户，则根据静态路由表或联盟规则进行路由。

 

API 增强功能之一， 应用程序通信 。

Live Communications Server 2005 提供了一种机制，可以在多台相互通信的服务器上部署相同的应用程序。当应用程序收到一个请求时，它可“标记”请求，也就是添加标头，以通知消息路径中该应用程序的所有下游实例它已经处理了该请求。Live Communications Server 2005 Enterprise Edition 利用此标记技术使运行在两台或更多台服务器上的应用程序实例能够进行通信。

 

 

 

参考文档：    Live Communications Server 2005 技术概述