CN101340310A - Ip电话和其他系统的配置 - Google Patents

Abstract

本发明提供了IP电话和其他系统的配置。提供了一种用于配置网络设备的方法，包括将该设备连接到与广域网相连接的局域网并且检测该设备尚未被配置。该方法还包括在该设备内访问位于广域网上的配置服务器的预定地址，并且发送对服务的配置请求。该配置请求是从电话发送到配置服务器的。该配置请求包括在广域网内定位局域网上的设备的网络标识符。该方法还包括在配置服务器处接收配置请求，并且在配置服务器处为该设备准备配置简档。该配置简档包括：i)该设备的服务地址，ii)将提供该服务的服务提供者的广域网地址。该方法还包括将该简档从配置服务器发送到该设备并在该设备中激活该简档，以便该设备被配置为经由该服务提供者访问该服务。

Description

IP电话和其他系统的配置

技术领域

本说明书一般地涉及计算设备，更具体而言涉及诸如电信设备、因特网协议(“IP”)电话设备和其他系统之类的末端用户设备的配置。

背景技术

IP电话领域的技术人员很清楚“会话发起协议(SIP)是一种用于创建、修改和终止与一个或多个参与者的会话的应用层控制(信令)协议。这些会话包括因特网电话呼叫、多媒体分发和多媒体会议”。(参见来自因特网工程任务组(“IETF”)www.ietf.org的请求注释：3261(位于http://tools.ietf.org/html/rfc3261的RFC 3261)。SIP可以为能够支持公共交换电话网(“PSTN”)的呼叫处理功能和特征中的至少一些以及许多高级的基于Web的特征的基于IP的通信提供信令和呼叫建立协议。

从RFC 3261开始，已经为SIP进行了许多工作。例如参见位于http://tools.ietf.org/html/draft-ietf-sipping-config-framework-12的Petrie等人的题为“A Framework for Session Initiation Protocol User Agent ProfileDelivery”的因特网草案(“Petrie”)。Petrie描述了用于多种重要的系统体系结构的配置场景(例如参见Petrie的“Simple Deployment Scenario”第4.1节和Petrie的“Device supporting multiple users from different ServiceProviders”第4.2节)。这些场景都是从被配置的端点的角度和必要关系来提出的，并且进行了关于被配置的网络元件的可用性的简化假设以帮助该过程。

至少对于一些应用和环境，Petrie存在许多缺点。Petrie没有论述Petrie的图1所示的配置服务器与提供它们的企业实体之间的必要关系。重要的是，Petrie：a)具体假设了用户位置处的被配置的网络基础设施，以便末端用户设备(端点)变为被配置，b)假设了用户的网络或者其接入提供者的网络与设备提供者(即设备厂商)或服务提供者(即语音或其他媒体通信服务的提供者)之间的在先关系，并且c)不允许端点基于单个设备厂商制造或发行的设备而针对许多可能的服务提供者之一。

Petrie一般也不适于住宅或小型企业设施中的IP语音(“VoIP”)网络的配置，并且不容易适用于远程和分支机构以及较大企业中的电信场景。Petrie假设本地网络是由受过训练的人员来管理的，而对于家庭或小型办公场所市场则不能假设这一点，对于较大企业的较小分支机构也不能假设这一点。

Petrie描述了如Petrie的图1所示的配置信息的三个来源。SIP服务提供者提供特定于个体用户的信息(特征预订等等)。设备提供者提供特定于设备的信息。本地网络提供者提供在本地网络的使用中指导设备的信息。Petrie假设本地网络由此信息的提供者所拥有并且将会对其使用设置约束(例如对咖啡店中的本地WiFi热点的带宽限制)。

Petrie的第5.1.1.1节相当详细地描述了设备将如何获得所需的本地网络配置简档。这将从本地动态主机配置协议(“DHCP”)服务器获得或通过使用本地相关的域名服务(“DNS”)来获得。Petrie中的本地DHCP和DNS服务器在实践中将需要由受过训练的人员更新。在小型企业、家庭或小型分支机构市场中不能假设存在这种人员。

Petrie的5.1.1.2节及其分节描述了用于获得设备配置简档的类似过程。同样，进行了关于被配置的网络资源的可用性的假设以帮助该过程，这些假设对于较小的未被管理的网络环境是无效的或者对其应用性施加了很大的部署约束。在设备简档的情况下，Petrie中描述了多种可能的方法。

在第一种方法中，服务提供者或设备制造者的预配置信息被用于定位设备简档服务器，这是能起作用的，但是却假定了设备制造者和服务提供者之间预先存在的关系以使设备完全可工作。可能不存在这种关系，或者可能存在多个这种关系(一个设备提供者对许多可能的服务提供者，或者许多设备提供者对一个服务提供者)，其中的每一种都是不明确的，因此最终的配置不能立即被完成。

在第二种方法中，假设了设备简档可利用本地网络域(由DHCP提供)来定位，以定位设备简档服务器，即设备简档服务器在提供的本地域中。在本地网络或者接入网络(例如因特网服务器提供者(“ISP”))中，DHCP和DNS服务器都将需要被配置以为设备简档服务器的定位提供正确的信息。这假设了在本地网络管理员与管理设备简档服务器的实体之间有预先存在的关系(有可能在较小网络环境中本地网络实际上未被管理)，或者在用户的接入网络(例如ISP)和该实体之间有关系-不能假设这种关系(即网络接入和设备维护者一般不会以任何方式与彼此相关)。

第三种方法是手动配置，这意味着某种级别的用户知识和交互，并且完全不是自动配置。

一般地，Petrie对于本发明所关注的小型企业和家庭系统是不够的，并且也不容易适用于较大企业中的多种分支机构和电信场景。Petrie假设本地网络将具有某种复杂度。例如，Petrie假设本地网络被配置有域标识符。Petrie假设本地DHCP服务器已被建立以包含此信息。与此有关的是下述暗含的假设：有负责该场地的人员，这些人员具有以具体要求的方式建立DHCP和/或DNS服务器的技能。

Petrie还假设了本地网络和维护设备简档服务器的实体之间或者用户的接入网络和该实体之间的预先存在的关系。虽然有时是可行的(例如ISP也是设备维护者和语音服务提供者)，但在一般情况下这些假设都是不真实的(所有的三个实体都可能是不相关的)。即使可以建立这种关系，由于基于因特网的系统的极为分布式、全球性和不断变化的性质，它们也可能随着时间而发展到极为复杂和繁复。

另外，Petrie假设向本地网络提供SIP代理服务器，该SIP代理服务器能够处理防火墙和网络地址转换(“NAT”)的问题以与外部SIP设施进行联络。在一般情况下这也不是真实的，尤其是在家庭和小型企业环境中更是如此。

在家庭和小型企业情形中，这些假设一般都不是有效的。有效的假设是缺乏经验的用户将会在消费者级的商店(例如大件电子设备商店)购买设备(SIP电话等)，或者收到服务提供者或设备提供者运送的通用设备，将其带到家中或小型企业中，并且将插入到其自己的网络中。他们将会预期该设备能够如期望那样地工作，而没有任何延迟，也无需任何不能从简短的说明书中获得的训练。对用户拥有或获得特殊技能的任何要求都会使这些设备变得在商业上没有吸引力。

除了对本地网络的要求外，Petrie没有涉及如何找到SIP服务提供者配置服务器的位置。假设这以某种方式被配置。

Petrie解决的一个问题是SIP用户代理(UA)(诸如IP电话、PC上的软电话客户端等之类的设备)的配置。Petrie设想这将发生在企业或其他机构内的LAN上、住宅小型网络中或公共“热点”等之中。当这些设备首次被安装时，其必须被提供以一些初始配置信息。这可包括(但不限于)：更新后软件加载；软键和其他控件和显示以及(对本发明重要的)SIP代理服务器的位置的初始配置。Petrie将这称为发现和登记阶段。UA将会利用与Petrie草案的图1所示的配置服务器的SIP预订/通知交互来接收其配置信息中的大部分。Petrie草案推荐为此服务器赋予公知的SIP用户id“_sipuaconfig”。它们将会为其所需的配置发出预订消息并通过相应的通知来接收它们。

此交互要求UA知晓配置服务器的地址和端口。Petrie描述了若干种可能的方法，其中包括手动加载。但是，Petrie预见为最常用的方法是DHCP的方法。DHCP常用于向UA提供SIP代理服务器(在逻辑上不同于并且不一定同于所需的配置服务器)的地址。代理服务器上使用的端口号可以作为可选的扩展被添加到DHCP服务器。利用代理服务器的地址、端口号和配置服务器的公知的用户id，可以构造配置服务器的SIP URI。对于这种方法的类似替换方案使用了基于DHCP提供的“本地域”的DNS查找，以尝试在本地域中定位所需的配置服务器。利用此信息，UA可尝试与配置服务器交互。

Petrie解决方案的特征在于：

·发生在单个企业或机构的LAN环境(在防火墙和/或NAT后)或某种其他的受管理环境中。

·本地网络为此操作做好了准备，因为将DHCP和DNS服务器配置为提供适当的信息，并且提供了配置服务器并向本地已知的SIP代理适当地注册了该配置服务器。

·有受过训练的人员为该网络服务。例如，为了利用包括代理服务器的端口地址和/或配置服务器的DNS条目的可选扩展来更新DHCP服务器，并且确保代理服务器知道配置服务器。

·LAN上的设备是由单个实体(单个厂商，例如本地系统管理者、增值贩卖商或制造者)配置的，从而适合于一起工作。

·如果配置服务器在外地网络(不同于本地网络)中，则配置服务器的信息可以为本地管理所知，并且可在本地网络中被成功配置，或者是在本地网络所连接到的接入网络中被配置的。这假设了本地或接入网络与容宿配置服务器的(一个或多个)网络之间的在先安排。

这种方法具有如上所述的若干缺陷和限制，并且还有本领域的技术人员现在将会想到的其他缺陷和限制。

诸如Vonage或Skype之类的当前的VoIP服务提供者使用专有的设备。Vonage提供一台特定的硬件，该硬件将标准的电话连接到其VoIP网络。Skype提供一种工作在标准的个人计算机上的软件客户端。但是，这些解决方案仅在这些提供者提供的网络上可操作。由于这种限制，系统是自配置的。这些系统的一种缺陷是用户不能从其选择的提供者购买设备并将其附接到这些网络。

发明内容

本说明书描述了SIP端点的动态配置，但是本说明书中没有任何地方排除了相同的技术被用于其他类型的设备的配置或使用其他网络技术的情形。

本说明书论述了Petrie没有论述的系统体系结构，以及Petrie的图1所示配置服务器与提供它们的企业实体之间的必要关系。重要的是，本说明书没有假设用户处的已配置网络基础设施变得已配置，没有假设用户的网络或其他接入提供者与设备提供者或服务提供者之间的任何在先关系，并且基于单个设备厂商所制造或发行的设备来允许端点被引导到许多可能的服务提供者之一。

本说明书描述了住宅或小型企业设施中的VoIP网络的配置，并且也很容易适用于远程和分支机构，以及较大企业的电信场景。

这里描述的相同技术也可很容易地适用于许多种较大的企业市场，以期能够降低它们的管理开销或使用容宿的VoIP服务而不是它们自己维护的服务。

虽然本说明书中的重点在于小型企业和家庭市场，但这里的教导也可用于分支机构和较大企业应用中的电信应用。设备可在通常没有来自这些大企业的受过训练的人员为其服务的分支机构和家庭场所中的本地网络上被配置。可以引导设备以与为小型企业和家庭应用连接到服务提供者网络所描述的方式相同的方式连接到企业网络。这种情况下的业务关系将存在于拥有方的大企业与设备提供者之间。设备提供者可以是设备制造者或者代表，或者可以是企业内的组织。它们将完全类似于在设备提供者和服务提供者之间描述的业务关系。在两种情况下服务器交互都可以是相同的。

本说明书描述了SIP电话和其他设备如何可以在本地网络上由缺乏经验的用户来配置而无需特定的网络装备。用户将在普通商店购买通用设备，或者设备可被运送给他们。设备将会来自厂商和零售商，两者都可能不与SIP服务提供者具有明显的关系。本说明书描述了一种业务关系和方法，其将允许设备访问所需的服务提供者用户和设备简档配置服务器，而无需用户方的繁重工作。

本说明书可以解决其中不可能装备网络的住宅或小型企业环境的服务配置问题。具体而言，没有能够建立本地DHCP或DNS服务器以允许结合外部设备配置服务(例如设备厂商或代表和/或服务提供者服务方案)来配置SIP设备的受过训练的人员。本说明书描述了设备提供者和服务提供者之间的业务关系，这种关系将使得能够实现可用来在用户干预尽可能少的情况下自动完成设备配置的方法。本说明书扩展了Petrie中描述的标准SIP配置。

本说明书设想了通过对等方法建立的本地SIP网络。结合Petrie理解，这种念头提出了一种“鸡和蛋”场景：一个SIP代理如何可在被配置之前被选择？本说明书中描述的方法可解决该“鸡和蛋”场景，并且可允许在先前未装备的本地网络上创建对等SIP系统。

附图说明

图1是根据一个实施例的可配置IP电话系统的示意表示。

图2是来自图1的系统的IP电话的示意表示。

具体实施方式

现在参考图1，根据一个实施例的可配置的IP电话系统一般示为50。系统50包括网络52，例如小型企业计算网络或家庭计算网络。网络52一般由通用防火墙/NAT 54和DHCP服务器58来服务。防火墙/NAT 54进而连接到广域网(WAN)62，例如因特网或较大的企业网络。WAN 62为来自服务提供者66和设备提供者70的各种网络组件提供互连点。

网络52包括多个与之相连接的设备，这些设备在本实施例中包括至少一个计算机77和至少一个IP电话78-1、78-2(统称为IP电话78并且一般称为IP电话78)。计算机77和IP电话78经由DHCP 58和防火墙54连接到WAN 82，因此计算机77和电话78能够与连接到WAN 62的硬件交互，所述硬件包括与服务提供者66和设备提供者70相关联的硬件。

服务提供者66充当网络52的服务提供者，并且包括用于网络52的所有适当的必要和/或基础设施，其中包括但不限于通过服务提供者CMS(“S/CMS”)78连接到WAN 62的管理服务器(“CMS”)74。服务提供者66还包括直接连接到WAN 62的容宿的代理82。

设备提供者70在IP电话78连接到网络52时帮助对其进行配设，并且包括设备配置管理服务器86(“D/CMS”)和STUN服务器90，这两个服务器都直接连接到WAN 62。STUN服务器90的结构和功能可通过参考位于http://www.ietf.org/rfc/rfc3489.txt的题为“Simple Traversal of UserDatagram Protocol(UDP)Through Network Address Translators(NATs)”的请求注释3489(“RFC 3489”)和进一步阅读这里的教导来理解。

用户U与网络52相关联。假设用户U不能定制DHCP服务器58或防火墙/NAT 54的操作或者以任何有意义的方式装备网络52。假设用户U在消费者电子设备商店购买了设备，例如电话78-2，或者有可能该设备通过某种手段被运送给他们。假设用户U期望将电话78-2连接到网络52并且预期能够利用电话78-2来进行电话呼叫。如图2所示，电话78包含SIP用户代理(UA)100和STUN客户端104，等等(再次参见RFC 3489，其中STUN作为一种用来解决SIP和其他协议的NAT穿越问题的协议被论述)。电话78还包括一套标准的电话电路，以管理语音和/或双音多频(“DTMF”)声音等等。

应当注意，这里的教导并不限于电话78，而是可以有很多种能够购买的具有SIP能力的设备。(实际上，这里的教导也适用于能够运行软件以模拟电话78的计算机77)。在最低限度上，电话可以是从简单的电话机到具有大显示屏和完整键盘的更大电话机之间的各种电话。这些变化的能力影响了用户获得或输入配置数据的方法。但是，最低限度上，这些电话能够进行语音电话呼叫并且将会包含一些DTMF信令的方法(键盘或其他)。对于本说明书来说，将假设最低限度的设备能力。

这里要澄清的是本教导反映了特定的实施例。SIP是协议的非限制性示例-协议不需要是SIP，它只是本实施例中使用的当前示例。另外，设备不需要是电话78，设备可以是任何需要被未经训练的用户自动配置并且通过诸如因特网之类的WAN进行通信的设备(例如VoIP网关、媒体服务器、IVR、网络游戏设备、诸如IPTV之类的娱乐设备、医疗监控、安保系统等等)。

出于配置目的，电话78的制造者将已经为电话78配备了引导程序(bootstrap program)，该程序将会尽可能地自动工作。还将向电话78提供唯一的标识符(设备id)。这例如可以是它的电气和电子工程师学会(“IEEE”)802媒体访问控制地址(“MAC”)地址等等。

当电话78首次被加电并且在与网络52相关联的局域网上连接时，电话78将会检测到它尚未被配置。为了支持配置，电话78的制造者(可能是也可能不是设备提供者70自身)已经为电话78配备了引导程序并且已经预配置了D/CMS 86以及可选的STUN服务器90在WAN 62上的地址(例如统一资源标识符(“URI”))。(注意，只有在要支持施加了NAT设备的配置场景时才需要STUN服务器90-如果设备已经在直接使用可路由的IP地址，STUN客户端和服务器则是不必要的)。在加电时，电话78将会已经被通用DHCP服务器58以标准的公知方式提供了在本地有意义的IP地址。引导程序将会与STUN客户端104使用此本地IP地址以联络STUN服务器90，并且获得由防火墙/NAT 54提供给它的全局有意义的IP地址和端口。引导程序随后将把电话78的设备id与所提供的NAT地址和端口相组合以形成对电话78唯一的有效SIP URI。它将使用此SIPURI作为其SIP FROM和CONTACT地址，以向D/CMS 86发出针对当前设备配置文件的SUBSCRIBE消息。该SUBSCRIBE请求将利用SIP To：字段被寻址到预配置的D/CMS 86URI，并且可能经由DNS查找被直接发送到D/CMS 86。可选地，D/CMS 86的URI可对应于设备提供者的网络(未示出)中的传入SIP代理服务器，其中来自电话78的SIP信令(预订/通知、SIP呼叫等等)一旦在该目的地网络中就可经由普通的SIP信令被引导和路由到该传入SIP代理服务器。

D/CMS 86可被配置为通过将电话78的设备id链接到型号和适当的修订版本来确定与电话78相对应的所需配置文件。电话78随后可在作为响应的通知消息中将所需的配置文件提供回电话78。预订可以保持开放，并且对电话78配置的任何更新都可在后续的通知消息中提供。

取决于电话78的厂商和服务提供者66之间的业务关系，电话78的设备提供者70可以可选地向电话78提供关于可从服务提供者66获得的预订的必要信息。存在若干种情况。

A)没有业务关系

这种情况与Petrie中描述的场景类似。在这种情况下，设备提供者70不提供帮助，服务提供者66将会向用户提供关于如何联络S/CMS 76的指示。

B)预安排的设备注册

i)位置预配置

可以建立一种关系，使得电话78的厂商(未示出)服务提供者66已经预先安排了使电话78与来自服务提供者66的特定供应相关联地被销售。例如，电话78可以在具有相关联的方案的服务提供者包装中销售。

在此类情形中，设备提供者70可将S/CMS 76的所需地址作为电话78的预配置的一部分来提供。在这种情形中，电话78将以与其连接D/CMS86的方式相同的方式联络S/CMS 76并接收任何必要的信息。这种预配置可在制造者完成、作为运送前的配置步骤完成，或者作为某个其他的制造后过程完成。

设备提供者70或服务提供者66随后可进行安排，使得诸如电话78之类的被具体预配置有与特定服务提供者66相对应的S/CMS 76的地址的电话可能通过客户访问商店或者通过直接运送而被提供到用户U(和/或其他像用户U那样的具有像网络52那样的网络的用户)。

可替换地，D/CMS 86可履行S/CMS 76的任务，直接将与在其他情况下已由服务提供者66提供的那些相对应的配置文件提供给电话78。D/CMS 86随后可能已被配置为保存服务提供者66所需的配置信息。作为另一替换方案，D/CMS 86可充当电话78和S/CMS 76之间的中继。在这两种情况下，可以使用与前述相同的配置，只不过D/CMS 86的位置取代与服务提供者66相关联的S/CMS 76被配置。

C)预注册的电话ID

作为将S/CMS 76的地址放在电话78的预配置文件中的一种替换方案，设备提供者70和服务提供者66可预先注册在服务供应时将会使用的每个电话78的设备id。设备提供者70或服务提供者66随后进行安排以可能通过客户访问商店或通过直接运送来向用户U(以及其他像用户U那样的用户)提供与特定服务方案和用户U相对应的、被具体预配置有这些预先已知的设备id之一的电话78。

这种预注册可分块完成或者以各设备id的群组的形式完成。当电话78联络D/CMS 86时，电话78的设备id可指示服务提供者和要提供的服务供应。与前一示例中一样，取决于设备提供者70和服务提供者66之间的关系，D/CMS 86或者可以将S/CMS 76的位置提供给电话78，或者可以自己执行访问S/CMS 76的功能。在前一情况下，S/CMS 76的URI可作为电话78的简档数据的一部分被返回。

D)用户注册的设备ID

另一个可能的业务关系是用户预注册电话78的设备id。用户U从设备提供者70获得电话78。设备id将以现成的方式供用户U使用。它可以被印刷在电话78上、包装上、说明书上等等。用户U将会联络服务提供者66以获得服务方案。作为此过程的一部分，服务提供者66将会请求设备提供者70的设备id和名称。服务提供者66随后将联络设备提供者70以对照服务方案注册设备id。电话78的注册随后可像以上在预注册的设备id那一节中描述的那样执行。与前述示例中一样，取决于设备提供者70和服务提供者66之间的关系，D/CMS 86或者可以将S/CMS 76的位置提供给电话78，或者可以自己执行S/CMS 76功能。在前一情况下，S/CMS 76的URI可作为设备配置简档数据的一部分被返回。

E)服务提供者注册的设备ID

另一种替换的业务关系由最初用户联络服务提供者66来驱动。用户U将会直接联络服务提供者66以安排服务方案。服务提供者66分配并配置与用户U和电话78相对应的设备id，并将此设备id提供给用户U以便在最初配置时输入。设备id可以以多种方式被提供给用户，例如通过电子邮件、通过电话联络、通过信件、由于客户访问而直接提供，等等。设备id的格式被设置成能够向D/CMS 86唯一地标识服务提供者66。(注意设备提供者70不需要能够得出特定的服务方案和用户，只要得出正确的服务提供者66即可)。用户U可以可选地已经预先在零售店或通过其他手段从设备提供者70购买了设备。或者，服务提供者66可以安排向用户U提供电话78，例如通过运送或者因为客户访问服务提供者的商店。服务提供者66随后将联络设备提供者70以对照其服务方案注册设备id，或者设备id可从在设备提供者D/CMS处已为服务提供者启用的预先安排的id群组中选出。在初始设备配置时，用户U被要求将其设备id输入到用户界面中，然后该设备id被与D/CMS 86的预配置的位置一起用来创建在联络D/CMS 86时将使用的SIP URI，该D/CMS 86随后可被映射到服务提供者66。与前述示例中一样，取决于设备提供者70和服务提供者66之间的关系，D/CMS 86或者可以将S/CMS 76的位置提供给电话78，或者可以自己执行S/CMS功能。在前一情况下，S/CMS 76的URI可作为设备配置简档数据的一部分被返回。

设备ID可被存储在电话78中的非易失性存储器中以便在诸如断开连接、电源故障、重启等等电源中断的情况下电话78可以自动地识别自身以便进行后来的操作。用户U不需要记住设备id。

F)设备配置时的用户服务注册

执行服务注册的另一种可能的方法是请求用户U在电话78的配置时进行服务注册。取决于电话78的类型，可以有多种实现与用户U的交互的方法。

如上所述，SIP地址(来自STUN服务器90或其他NAT穿越过程)在电话78的配置阶段被交换以允许预订/通知过程。这些地址的拥有可允许与用户U的交互以获得关于他们所选择的服务方案的信息或者帮助他们选择服务方案。

对于没有显示屏和完整键盘的电话78的最简单版本，可以在电话78和D/CMS 86之间建立语音连接。这种语音连接可利用标准的SIP方法或类似方法实现。D/CMS 86或电话78可被配置为在与D/CMS 86的初始配置联络时发起连接。

在电话78注册时，电话78将会振铃(或以某种其他方式发出警告)，并且当用户U应答时，他/她将被以语音对话的形式提问以便获得完成服务注册所需的信息。此对话可以是与人类服务代表的对话，或者可以经由诸如交互式语音响应(“IVR”)系统之类的自动服务器进行。用户U可被提示以DTMF回复，或者通过语音回复(如果D/CMS 86配备有自动语音识别设备的话)。

对于具有显示屏和键盘的能力更大的电话78(可能甚至还是计算机77)，服务注册对话可通过表单交换来完成。这些表单可以以与即时消息传递交换相同的方式例如利用SIP Message消息在电话78和D/CMS 86之间来回传递，或者可以利用超文件标记语言(“HTML”)经由Web访问或其他手段来进行。

还可能进行混合模式文本和语音协商。D/CMS 86可将选项列表以文本形式发送到电话78的显示屏并接受文本或语音形式的回复。对于这种方法，在电话78和D/CMS 86之间可建立语音和文本连接。

对于此方法，用户U可能已经注册了服务方案或者可以请求帮助选择服务提供者和方案。对话最初可询问用户U是否已经注册了方案，如果是则像前一方法中那样询问提供给用户U的服务提供者身份和注册号。如果用户请求帮助选择方案，则对话可提供来自设备提供者70与之有业务关系的服务提供者的关于方案的信息。这可以由D/CMS 86独自完成，或者由D/CMS 86和/或各种服务提供者提供的其他服务器合作完成。当已经选择了服务提供者和方案时，可以按前面的小节中描述的方式执行服务配置。这可以由D/CMS 86自己完成，或者D/CMS 86可向电话78提供所选服务提供者66的S/CMS 76的位置。

配置服务的切换(Handoff)

在前述方法中的任何一种中，对电话78的简档数据的不间断维护都可以由服务提供者66提供而不是由设备提供者70实现。这对于服务提供者66维护更完整的服务是有用的。这对于设备提供者70也可能有用，因为它允许了下载最新的软件、许可证检查、库存管理和其他功能，它还消除了对电话78的实际简档数据的不间断维护的负担，而这种负担可能变得非常得大。

在最初与D/CMS 86连接时，电话78可被提供以与该特定电话78相对应的初始配置(例如初始/更新后软件加载、包含默认键配置的设备简档、通用服务设置，等等)。在所有的特定于电话的通用配置已被完成之后(这可能要花不止一个预订/通知周期来完成)，当前的D/CMS 86可向电话78发出简档更新通知，该通知包含除D/CMS 86之外的D/CMS的另一个不同实例(未示出)的位置，该实例可能由服务提供者维护(例如服务提供者66，在服务提供者66维护的D/CMS中)，或者由某个其他的第3方实体维护，并且可能与S/CMS 76驻留在相同的物体服务器上，也可能不与S/CMS 76驻留在相同的物体服务器上。基于此变化，电话78可放弃对当前D/CMS 86的现有预订，然后预订到D/CMS的该不同实例。基于电话78中保存的存储数据(例如服务提供者的D/CMS的URI，其可能与S/CMS 76相同)，对于电话78的该简档的进一步预订操作随后可被引导到D/CMS的该不同实例。如果先前被切换了的电话78由于某种原因再次到达原来的D/CMS 86，该电话78可以以相同的方式再次被切换。

在切换并预订到D/CMS的该不同实例之后，对电话78的简档数据的任何本地生成的变化(例如用户对键重新编程等)随后可通过公知的手段(例如经由HTTPS或类似方式)被推送到D/CMS的该不同实例，并且更新由D/CMS的该不同实例保存的简档数据的拷贝以便后来检索。D/CMS的该不同实例不需要具体知晓该数据的含义，因为它不是电话78特定的，而是由电话78指定的，因此更新可以被透明地处理。可能存在一些原因使得服务提供者确实想要能够访问此数据和/或能够对其使用应用策略-这并不被禁止，但要求特定的处理。

特定于服务提供者的定制

在上述方法中的任何一种中，由于设备id是设备提供者70已知的，并且可以被映射到特定的服务提供者66，因此设备提供者70可提供对该服务提供者66特定的内容。例如，设备提供者70可为除服务提供者66之外的或者包括服务提供者66的不同服务提供者维护不同的定制软件，或者为具有不同的默认键映射、目录项等等的电话78维护不同的简档。

设备和服务提供者之间的数据交换

上述设备意味着设备提供者70和服务提供者66之间的商业协议和系统接口。如果设备提供者70将设备引导到服务提供者66，则设备提供者70可预期收到为该指引而支付的报酬(可能采取付款的形式)。为了收到报酬，可以实现一种方法，利用该方法设备提供者70可识别已被提供以此服务的电话78，这种方法不能被服务提供者66否认，因为设备提供者70和服务提供者66需要在他们的系统之间交换包括设备id在内的信息。这些关系可以是多对一(即一个设备提供者70可能与一个或多个不同的服务提供者66有协议，并且一个服务提供者也可以与一个或多个不同的服务提供者66有协议)。有若干种实现上述内容的方法。

A)对于设备提供者70代表服务提供者66操作CMS(例如D/CMS86或甚至S/CMS 76本身)或者充当S/CMS 76和电话78之间的交互中的中继的情况下，可以建立协商以便设备提供者70所操作的CMS可从S/CMS 76提取服务方案标识符。这可以例如利用HTTPS或类似的公知手段来完成，其中设备提供者70向S/CMS 76发送要被映射的电话78的设备id，并且服务提供者66返回该设备的相应服务实例id和与用户U相对应的相应用户服务方案和简档数据。可以例如利用加密散列或其他技术来制作电话设备id和服务实例id，以便它们分别只能由设备提供者70创建给服务提供者66。例如，设备id可以是设备MAC地址的散列，而服务id可以是用户的SIP记录地址(“AOR”)的散列。这些加密的id可充当为计费目的而设置的被认可的id。

B)另一种情况是设备提供者70将预期服务提供者66向设备提供者70提供被认可的id。此情况的示例是前面描述的“服务提供者注册的设备ID”和“用户注册的设备ID”场景。在S/CMS 76处的配置过程之后，服务提供者66可向设备提供者70指示具有特定设备id的电话78已被配置和验证。设备id可利用上述加密技术来形成。这种情况下的数据交换将由服务提供者66发起，并且可使用诸如HTTPS之类的公知手段，从而向D/CMS 86提供经验证的设备id，并且D/CMS 86返回确认id。D/CMS 86随后可允许该特定设备id被配置并且投入使用，如前所述。

C)作为上述情况的变体，服务提供者66可预先验证某个范围的设备id，设备提供者70随后可允许这个范围的设备id被配置和投入使用。这可以使用与服务提供者66和设备提供者70相关联的系统之间的相同交换，不同之处在于提供了多个设备id。

D)另一种情况是服务提供者66可预期设备提供者70向服务提供者66提供被认可的id。此情况的示例是前面描述的“设备配置时的用户服务注册”场景。在D/CMS 86处的配置过程之后，设备提供者70可向服务提供者66指示具有特定设备id的电话78已对照特定服务id被配置并验证。设备id和服务id可利用上述加密技术来形成。这种情况下的数据交换将由设备提供者70发起，并且可使用诸如HTTPS之类的公知手段，从而向S/CMS 76提供经验证的设备id和服务id，并且S/CMS 76返回确认id。关于特定用户的额外信息也可在此时被传送到服务提供者66，例如用户的SIP AOR、任何偏好以及所选择的特定服务方案。D/CMS 86随后可允许特定设备id被配置，并且S/CMS 76可允许与该服务id相对应的服务id被配置并且投入使用，如前所述。

E)作为上述情况的变体，设备提供者70可预先验证某个范围的服务id，服务提供者66随后可允许这个范围的服务id被配置和投入使用。这可以使用与设备提供者70和服务提供者66相应的系统之间的相同交换，不同之处在于提供了多个服务id。

为了实施上述情况，操作CMS的实体(设备提供者70或服务提供者66)具有禁用以下电话78的能力：对于这种电话78该实例没有接收到有效服务提供者和/或设备提供者配置的证据，或者这种电话78在其他方面看起来是无效的。相关的CMS具有更新电话78的配置的能力。这通常用来更新简档数据、校正设备软件缺陷等等。但是，CMS可发出将禁用电话78的配置，或者简单拒绝提供初始软件加载或任何配置。可选地，取决于特定的提供者间交互，在电话78接收到其设备配置后可设置超时。如果在该超时期间没有接收到被认可的id，则可发出配置以禁用电话78。

HTTP的使用

先前的小节描述了利用SIP预订/通知能力完成的注册过程。此过程有多个优点。首先，电话78可以把SIP作为其普通功能的一部分来使用，因此将会默认具有该能力。其次，永久预订的使用可以允许D/CMS 86或S/CMS 76在任何所需的时刻更新电话78。电话78不需要查询相关的CMS(即D/CMS 86或S/CMS 76)。在有大量电话78(或计算机77)的情况下，这可能造成严重的可缩放性问题。另外，如上所述，SIP过程在NAT穿越方面可能有困难。HTTP在NAT穿越方面没有困难。但是，HTTP不具有预订/通知的可能。如果电话78将会就任何所需的更新而周期性地查询配置服务器，上述过程则可以使用HTTP来取代SIP。上述对话过程可以通过HTTP利用HTTP表单交换来完成，并且语音对话例如可通过使用专用的applet或其他公知的手段来实现。

除SIP或HTTP外的其他协议也是可行的。

安全性和加密

可以理解，出于隐私和安全原因，可能想要对配置过程进行加密。SIP和HTTP都提供了公知的加密机制，用于对控制和媒体流两者的保密和验证。这些公知的机制被用于此目的。

虽然以上提供了关于某些实施例的论述，但应当理解可以构思这些实施例的组合、变化和/或子集。

应当注意，这里引用的所有第三方文档都通过引用被结合在此。

Claims (15)

1.一种用于配置网络设备的方法，包括：

将所述设备连接到网络；

在所述设备内访问位于所述网络上的配置服务器的预定地址；

发送对服务的配置请求；所述配置请求是从所述设备发送到所述配置服务器的；所述配置请求包括在所述网络内唯一的设备标识符；

在所述配置服务器处接收所述配置请求；

在所述配置服务器和与所述配置服务器通信的至少一个额外的配置服务器处为所述设备准备配置简档；所述配置简档包含将提供所述服务的服务提供者在所述网络上的地址；以及

从所述配置服务器中的任何一个将所述简档发送到所述设备。

2.如权利要求1所述的方法，其中所述对服务的请求包括多个服务选项，其中所述服务选项包括以下各项中的至少一个：从多个服务提供者中对所述服务提供者的选择，以及电话呼叫方案。

3.如权利要求2所述的方法，其中，在接收所述配置请求之后，所述配置服务器在所述设备处的服务方案中呈现多个选项以供用户选择并且接收对所述选项的选择，并且所述配置服务器基于所述对选项的选择来准备所述配置简档。

4.如权利要求3所述的方法，其中所述多个选项是经由以下各项之一来呈现的：语音对话，文本，或者语音和文本形式对话的组合。

5.如权利要求1所述的方法，其中所述网络是企业网络的一部分，并且所述服务是通信服务和设备配置服务之一；所述服务是由所述服务提供者提供的。

6.如权利要求5所述的方法，其中所述设备标识符是预先注册的、提供到多个所述设备的一批唯一设备标识符之一，以便当所述配置请求被接收到时所述配置服务器识别出所述设备标识符。

7.如权利要求1所述的方法，包括多个配置服务器，并且其中所述配置简档的一部分是由所述多个配置服务器之一准备的，并且所述配置简档的其余部分是由所述多个配置服务器中的另一个准备的。

8.如权利要求7所述的方法，其中所述配置服务器管理计费系统，该计费系统合作生成所述设备通过所述服务提供者访问的服务的服务发票，并且所述计费系统是基于所述设备提供者操作的所述配置服务器从所述服务提供者操作的所述配置服务器接收唯一设备标识符的。

9.一种用于向附接到网络的设备提供配置信息的方法，包括：

在所述设备处从第一网络配置服务器接收所述配置信息的第一部分；

在所述设备处从第二网络配置服务器接收所述配置信息的第二部分；以及

将关于所述设备的信息从所述第一网络配置服务器发送到所述第二网络配置服务器。

10.一种用于向附接到网络的设备提供配置信息的方法，包括：

在所述设备处从第一网络配置服务器接收所述配置信息的第一部分；

在所述设备处从第二网络配置服务器接收所述配置信息的第二部分；并且

其中所述第二服务器的网络地址由所述第一服务器提供给所述设备。

11.如权利要求10所述的方法，其中所述第一服务器通过提交被寻址到位于所述设备处的用户的查询来识别所述第二服务器，其中所述查询是口头、文本或语音和文本的组合之一，并且其中对所述查询的响应是由所述用户利用双音多频信号来提交的。

12.如权利要求10所述的方法，其中，当所述设备被指引到所述第二服务器时，所述第二服务器将会向所述第一服务器提供对所述第二服务器的动作的指示。

13.如权利要求12所述的方法，其中所述指示是被认可的。

14.如权利要求1所述的方法，还包括修改所述配置简档以指定与所述服务提供者不同的服务提供者，以便使得对所述服务的提供被从所述服务提供者切换到所述不同的服务提供者。

15.如权利要求1所述的方法，其中所述配置服务器与设备提供者相关联，并且所述额外的配置服务器与所述服务提供者相关联；所述方法还包括修改所述配置简档以指定所述服务提供者而不是所述设备提供者，或者指定所述服务提供者而不是所述设备提供者。

Images