处理电话会话的系统和方法
处理电话会话的系统和方法
【专利说明】处理电话会话的系统和方法
[0001]本申请是申请日为2009年04月02日，申请号为200980116961.6，发明名称为“处理电话会话的系统和方法”的申请的分案申请。
[0002]相关申请的交叉引用
[0003]本申请要求以下专利申请的利益:于2008年4月2日递交的名称为“System andMethod for Processing Telephony Sess1ns” 的申请号为 61/041，829 的美国临时申请;于 2008 年 5 月 22 日递交的名称为“System and Method for Processing SMS Messages”的申请号为61/055,417的美国临时申请，于2008年9月26日递交的名称为“System andMethod for Processing Telephony Sess1ns” 的申请号为 61/100，578 的美国临时申请，于2009年3月2日递交的申请号为61/156，746的名称为“System and Method forProcessing Telephone Sess1ns”的美国临时申请，以及于2009年3月2日递交的申请号为 61/156，751 的名称为“System and Method for Processing Telephony Sess1ns” 的美国临时申请，以上所有申请的全部内容通过引用并入本文。
技术领域
[0004]本发明一般涉及电话领域，且更具体地涉及用于处理电话领域内的电话会话的新的和有用的系统和方法。
【背景技术】
[0005]在最近十年，网络语音电话(VOIP)的出现和立法以新的技术、商业模式和服务提供者革新了通信行业。软件和商用硬件现在提供了昂贵的载体设备的替代物。人们可在开放源软件应用(例如Asterisk和FreeSwitch)中实现可扩展呼叫转换和语音应用逻辑。但是，这些新的应用的堆积引发了新的复杂性和挑战，需要新的技术组来部署、开发和维持。部署电话服务需要语音网络和编解码器、硬件或服务的知识，以连接服务器与共用电话基础设施、对硬件以及这硬件的持续配置进行资本投资。这些负担只是开发实际应用的先决条件，其需要开发者进行新的语音、工具和开发环境的培训。即使是当前试图将模型调整为与网络开发例如语音可扩展标记语言(VoiceXML)更加相似的电话应用，也需要致力于学习新语言和理解电话交互。这些服务的持续操作和维护需要团队采用新的分析工具、性能标准和调试方法。即使是开发最简单的语音服务(例如所谓的“电话树”)也需要对专门的基础设施、技术和操作进行大量的前期和持续的投资。因此，在电话领域中需要用于处理电话会话的新的和有用的系统。本发明提供了这样的新的和有用的系统和方法。
【发明内容】
[0006]用于处理电话会话的优选的实施方式的方法包括使用应用层协议与应用服务器通信、用呼叫路由器处理电话指令、以及创建可通过应用程序接口(API)访问的呼叫路由器资源的步骤。优选的实施方式的方法和系统使网络开发者能够在电话的神秘世界里使用他们现有的技术和工具，像网络编程一样容易地进行电话应用开发。方法和系统使用熟悉的网站访问者模式与网络开发者的应用交互，其中电话呼叫的每个步骤与传统的页面浏览相似。在这种模式中，开发者重新利用他们现有的工具和技术，包括熟悉的概念例如HTTP重定向、通过AP1、cookie和mime类型响应访问资源以构建复杂的电话应用。处理电话指令和创建可通过API (呼叫路由器API)访问的呼叫路由器资源的方法协同起作用，以利用多个呼叫路由器资源以及通过呼叫路由器(优选地为很多网络开发者熟悉的REST API)提供的信息来使能无状态(stateless)和简单电话语言。在一个实施方式中，电话指令组可具有少于十来个的动词用于简化语言，以使得开发者可快速地学习和实现电话应用，同时呼叫路由器API完善简单的电话指令以使能复杂的电话应用。
[0007]本发明提供了一种处理网络的电话会话的方法，所述网络包括应用服务器和呼叫路由器，所述方法包括以下步骤:
[0008]使用应用层协议与所述应用服务器通信；
[0009]用所述呼叫路由器处理电话指令；以及
[0010]创建可通过呼叫路由器应用程序接口(API)访问的呼叫路由器资源。
[0011]所述方法还可包括将电话会话映射到统一资源标识符(URI)的步骤，其中所述URI可与所述应用服务器相关联。
[0012]所述方法还可包括将所述电话会话的状态信息嵌入到所述URI的步骤。
[0013]所述应用服务器所需要的所有状态信息可嵌入在所述URI中。
[0014]所述方法还可包括以下步骤:向所述应用服务器发送请求；将所述电话会话的状态信息嵌入到所述请求中；以及从所述应用服务器接收响应；其中所述响应包含所述电话指令。
[0015]发送的步骤和接收的步骤可以使用超文本传输协议(HTTP)来执行。
[0016]所述电话指令可以用可扩展标记语言(XML)编码。
[0017]所述方法还可包括利用所述请求发送数字签名的步骤，其中所述数字签名可适合于由所述应用服务器用于账户验证。
[0018]所述数字签名可以是由密钥生成的加密散列，其中所述密钥可以由呼叫路由器和所述服务器共用，且其中所述加密散列可包括在所述URI中。
[0019]所述方法还可包括顺序地处理电话指令的步骤。
[0020]所述方法还可包括通过公用交换电话网络(PSTN)从电话号码启动所述电话会话的步骤。
[0021 ] 所述方法还可包括由从短消息服务(SMS)系统接收的消息启动所述电话会话的步骤。
[0022]所述方法还可包括由应用服务器通过所述呼叫路由器API启动所述电话会话的步骤；其中映射到所述电话会话的初始URI可由所述应用服务器提供。
[0023]所述呼叫路由器资源可由可寻址URI处的外部设备访问。
[0024]所述呼叫路由器API实质上可以是表述性状态转移(REST)API。
[0025]所述方法可包括以下步骤:将状态信息存储在呼叫路由器资源的URI中；修改呼叫路由器资源以改变所述呼叫路由器的状态；以及根据所述呼叫路由器API而与所述呼叫路由器的媒体交互。
[0026]所述方法可包括以下步骤:从所述应用服务器接收API请求以与资源交互；以及基于与资源的所述交互而对API请求进行响应。
[0027]所述方法可包括创建从由呼叫资源、媒体资源、呼入地址资源、账户资源和呼叫者身份(ID)资源组成的组中选择的资源。
[0028]所述方法可包括:用所述呼叫资源改变所述电话会话的状态；用所述媒体资源访问媒体；用呼入地址资源修改呼入地址；用所述账户资源修改账户信息；以及用所述呼叫者ID资源修改呼叫者ID信息。
[0029]所述电话指令可从由以下项组成的组中选择:连接到电话设备、播放媒体文件、将文本转换为语音、检测来自电话设备的输入、以及连接到新的URI。
[0030]所述方法可包括创建呼叫资源；其中所述呼叫资源可用于改变所述电话会话的连接。
[0031]改变呼叫会话的连接可包括:加入电话会话、拆分电话会话、以及转移电话会话。
[0032]本发明还提供了一种处理电话会话的系统，包括:
[0033]呼叫路由器，该呼叫路由器连接到电话设备并使用应用层协议与应用服务器通Is ;
[0034]用于应用服务器的URI，该URI与电话地址相关联；
[0035]电话指令，该电话指令由所述呼叫路由器顺序地执行；以及
[0036]呼叫路由器API资源，该呼叫路由器API资源由所述呼叫路由器创建并可由所述应用服务器通过呼叫路由器API访问。
[0037]所述应用层协议可以是HTTP协议，且其中所述电话指令可用XML编码。
[0038]所述请求可封装呼叫的状态。
[0039]所述呼叫路由器API可以是REST API。
[0040]所述资源可从由呼叫资源、媒体资源、账户资源、呼入地址资源和呼叫者ID资源组成的组中选择。
【附图说明】
[0041]图1是本发明的优选的方法的流程图表示。
[0042]图2A、2B、3A和3B是本发明的优选的实施方式的示意图。
[0043]图4A-4C分别是HTTP GET请求、HTTP POST请求和HTTP GET请求的例子。
[0044]图4D-4F是HTTP请求的例子。
[0045]图5A和5B是XML响应的例子。
[0046]图6是呼叫路由器请求和响应的例子。
[0047]图7-15是包括本发明的优选的方法的原理的各种应用的示意图。
[0048]图16是与本发明的优选的方法的数字标记部分相关的子步骤的流程图表示。
【具体实施方式】
[0049]本发明的优选的实施方式的以下的描述不意味着将本发明限于这些优选的实施方式，而是意图使本领域任何技术人员能够实施和使用本发明。
[0050]1.用于处理电话会话的方法
[0051]如图1、2A、2B、3A和3B中所示出，用于处理电话会话的优选的实施方式的方法10包括使用应用层协议与应用服务器通信的步骤S110、用呼叫路由器处理电话指令的步骤S120、以及创建可通过应用程序接口(API)访问的呼叫路由器资源的步骤S130。优选的方法还可包括以下解释的其他步骤和/或子步骤。
[0052]1A.与应用服务器通信
[0053]如图1中所示，使用应用层协议与应用服务器通信的步骤SllO优选地包括以下子步骤:启动电话会话S1、将呼叫映射到统一资源标识符(URI) S3、发送请求到与URI相关联的服务器S5、处理与电话会话的状态对应的请求S7、以及从服务器接收响应S9。使用熟悉的网站访问者模式的一个挑战是第三方网络应用可能暴露包含敏感数据的URI或暗示可恶意操作应用数据库的行为 的URI。在优选的实施方式中，呼叫路由器使用账户指定密钥加密地签名向外发送到客户网络应用的请求。更具体地，与应用服务器通信的步骤包括数字地签名请求参数的另外步骤S4以及验证请求参数S6的数字签名的另外步骤S6。只有呼叫路由器和应用服务器知道所述密钥，所以包括用所述密钥签名的参数(URL、POST数据、报头等)的请求可在允许这样的操作之前被检查真实性。这个方法还用低CPU开销提供对安全链接(HTTP)的真实性验证。
[0054]陈述了启动电话会话的步骤SI起作用以接收进来的消息。该消息优选地是来自PSTN(公用交换电话网络)连接的设备或互联网可寻址设备的呼叫，例如固定电话、蜂窝电话、卫星电话、网络语音电话(VOIP)、SIP设备、Skype, Gtalk或任何其他的适当的PSTN连接的或互联网可寻址的语音设备。消息可以可选地是短消息服务(SMS)消息。SMS网关服务器可以可选地通过短消息服务中心(“SMS-C”)连接到SMS网络、直接连接到7号信令系统(SS7)电话网络，或由任何其他的适当的SMS网关提供者进行，且消息优选地从网关由呼叫路由器接收并转换为可通过公共互联网例如HTTP发送的格式(例如URI)，该发送基于SMS的接收地址例如短码、或直接向内拨叫(DID)、或其他的适当的唯一接收标识符。消息可以可选地是多媒体消息、传真发送、电子邮件、或任何其他的适当的消息发送媒体。PSTN设备的初始电话号码优选地使用呼叫者ID捕捉，但是任何其他的适当的ID都可被捕捉到，例如VOIP提供者ID、SMS设备号、电子邮件地址或短码。被拨叫的电话号码、EIN和/或计费标识符和/或呼叫的日期和时间还可优选地包括在会话信息中。认证ID可以另外地或可选地包括在会话信息中。
[0055]在一个变动形式中，步骤SI还起作用以通过HTTP或从在第三方服务器上运行的应用发送到呼叫路由器的其他请求来启动电话会话(例如电话呼叫)。在这个变动形式中，运行在服务器上的应用优选地为呼叫路由器指定初始URI以用于步骤S3中的电话会话，以及指定要拨叫的电话号码(或其他可寻址的目标)和源电话号码(呼叫者身份(id))。在这个变动形式中，呼叫路由器API优选地由应用服务器用来从呼叫路由器请求向外发出的呼叫。
[0056]陈述了将呼叫映射到统一资源标识符(URI)的步骤S3起作用，以使电话会话能够被转换为可由标准网络服务器和网络应用来处理的格式。该映射优选地使用呼叫路由器来执行。初始URI优选地在呼叫路由器由(可在第三方服务器上运行的)网络应用或呼叫路由器账户所有者预先指定。更加优选地，初始的URI通过呼叫目标的唯一标识符例如DID(直接向内拨叫)电话号码或VOIP SIP地址被分配给该呼叫。URI可以可选地由远程服务器或其他的适当设备或方法指定。在一个变动形式中，URI可用于封装来自被启动的电话会话的状态信息或状态信息的一部分，例如始发电话号码、被拨叫的电话号码、呼叫的日期和时间、呼叫者的地理位置(例如，国家、城市、州和/或邮编)、和/或唯一的呼叫ID。包括在URI中的信息可以URI模板的形式被包括在其中。例如URI缺省模板可以是:http://demo, twil1.com/myapp/ {被拨叫的电话号码} / {始发电话号码}或者http://demo,twil1.com/myapp/fo0.php ? dialed_number = {被拨口lI 的电话号石马}&originating_number = {始发电话号码}。
[0057]步骤S4起作用以数字地签名请求参数。如图16中所示，步骤S4优选地确定呼叫路由器账户所有者，且更加优选地，查找账户所有者的唯一 ID或密钥并签名一组请求参数。步骤S4优选地通过生成请求参数的加密散列(hash)来实现，优选地包括URI以及具有与呼叫路由器账户所有者相关联的唯一密钥的任何的请求体参数(例如，在HTTP POST的情况下)。加密散列优选地通过将请求参数附加到初始一组请求参数上的方式而生成。散列优选地附加到URI，但是如果散列特别长(即，具有大量的参数)，则散列可包括在对大小没有限制的HTTP报头中。在步骤S4的变动形式中，至少一个敏感参数可在散列被处理之前使用账户所有者的密钥来单个地加密。在另一个变动形式中，加密凭证授权系统例如Oauth (oauth.net)可以可选地用于对请求进行电子签名。
[0058]步骤S5起作用以向服务器发送请求。优选地，请求被发送到URI，且更加优选地，请求被发送到在步骤S3中所映射的URI。请求优选地包括由所述一组请求参数(作为数字签名起作用)计算得到的加密散列，但是如果参数被确定为包含敏感数据，则请求可以可选地包括单个加密的请求参数。服务器优选地是第三方服务器，且更加优选地，服务器运行网络应用。请求优选地通过网络被发送到服务器。在一个变动形式中，请求被发送到局域网上的本地服务器。在另一个变动形式中，请求被发送到在始发呼叫的设备上本地运行的服务器。在又另一个变动形式中，请求可被发送到多个服务器。请求优选地封装有来自被启动的电话会话的状态信息的至少一部分，例如始发电话号码、被拨叫的电话号码、呼叫的日期和时间、呼叫者的地理位置(例如，国家、城市和/或州、邮编)、和/或唯一的呼叫IDo更加优选地，请求封装了呼叫的所有状态信息，但是可以优选地不包括状态信息或包括部分状态信息。来自被启动的电话会话的状态信息优选地通过请求体中的HTTP POST、请求URI中的HTTP GET、HTTP报头参数来发送以模拟网络浏览器的数据流，或通过任何的组合方式或适当的可选方式发送。如果在呼叫路由器的操作过程中产生新的状态信息，则优选地向应用服务器作出请求以传递新的状态并请求新的电话指令。优选地，新的状态信息不被呼叫路由器保持或对其内部起作用，而是被传送到应用服务器以用于处理。可选地，部分状态信息优选地被存储在呼叫路由器上直到获得全面的更新状态，并随即被传送到应用服务器。例如，在当新的呼叫状态被获得并被传送到应用服务器之前，应用服务器可指定在键盘上应被按下的多个数字，而不只是一个。在一个变动形式中，来自被启动的电话会话的信息可以是包括在HTTP POST请求中的网络形式的提交。请求可包括来自电话会话的任何状态信息，例如始发电话号码、被拨叫的电话号码、呼叫的日期和时间、和/或唯一的呼叫ID、电话呼叫的当前状态(等待、正在进行、已完成等)、或电话行为的结果(包括双音多频(DTMF)数字处理)、或录音表示或录音的链接、或上一个命令的状态、或其他的呼叫状态。HTTP GET请求、HTTP POST请求以及HTTP GET请求的例子分别在图4A、4B和4C中示出。用于SMS消息发送的HTTP通信的进一步的例子在图4D、4E和4F中示出。向服务器的HTTP请求(或任何适当的请求通信)优选地遵循RESTful设计的原则。在本文档中RESTful被理解为描述了如本领域中所公知的表述性状态转移结构。RESTful的HTTP请求优选地是无状态的，因此从呼叫路由器发送到应用服务器的每个消息优选地包含应用服务器的操作和应用服务器的响应生成所需要的全部信息。呼叫路由器和/或应用服务器优选地不需要记住或存储先前的通信以获知所述状态。文档、媒体和应用状态优选地被浏览作为可寻址资源，与通过请求参数例如HTTP GET或HTTP POST参数或请求体内容而被提供到资源的数据进行组合。这样的请求数据可包括呼叫资源的更新后的表示，或作为呼叫路由器操作的结果生成的其他呼叫状态数据，例如键盘上被按下的数字或所生成的录音。每个请求中包括的状态信息可包括唯一的呼叫标识符、呼叫状态数据例如呼叫是正在进行中还是已完成、呼叫者的呼叫者ID、被呼叫的电话号码、关于呼叫者的地理数据、和/或任何适当的数据。但是，可使用变化水平的RESTful通信(无状态)，例如通过使用cookies、会话追踪、或任何适当的设备以模仿普通的网站访问者模型。优选地，与每个请求一起发送的数据完全可使应用服务器能够确定要执行的呼叫的下一个状态。RESTfulness优选地不排除使用外部数据源例如数据库，以查询另外的数据以记录呼叫元数据，或确定应用逻辑。
[0059]步骤S6起作用以验证请求参数的数字签名。如图13中所示，在服务接收到请求之后，请求参数优选地被检查和/或解析以用于散列。加密的散列优选地包括在HTTP请求的URI中，但是可以可选地包括在请求的HTTP报头中。如果请求不包括散列，且网络应用服务器以使能散列函数检查作为安全措施，则请求优选地被确定为假的，其可能包括一一例如一一恶意请求、错误路由请求、被破坏的请求和应用服务器不需要的任何其他请求。如果所述一组请求参数包括散列，则散列优选地从请求中提取，且客户网络应用的密钥(即，存储在呼叫路由器上与客户账户密钥相同的密钥)优选地用于生成所接收到的参数的服务器侧的加密散列。服务器侧加密散列优选地与包括在请求中的散列相比较，且如果散列不匹配，则请求优选地被确定为假。但是，如果服务器侧加密散列与请求散列相匹配，则请求优选地被确定为真实且准备好在应用服务器上进一步处理。在以上提到的步骤S4的变动形式中，其中敏感参数可使用密钥被加密，步骤S6优选地包括解密敏感参数。应用服务器和操作应用的第三方优选地负责完成这个验证步骤，但是验证可以可选地通过单方来完成，例如当单方操作应用服务器和呼叫路由器时来完成。如果请求认证对应用来说不重要，则应用服务器可以可选地设置为忽略包括在请求参数中的散列。
[0060]陈述了处理与电话会话相对应的请求的步骤S7起作用，以执行对包括在请求中的数据的至少一部分的处理。处理功能优选地在第三方服务器上执行。处理功能可包括记录包括在请求中的数据和/或与呼叫会话有关的元数据、路由到另一个UR1、执行包括在请求中的数据的至少一部分的数据库查询、语音识别处理、或任何其他的适当的处理功能。处理功能可再利用来自其他的商业应用的逻辑和数据，例如客户数据库和/或购物车应用，其可使用呼叫者id或呼叫者提供的信息来链接。状态信息优选地与来自呼叫路由器的每个请求通信，且优选地，应用服务器不需要应用状态。可选地，应用服务器可通过使用HTTPcookies、会话和/或数据库记录来存储与呼叫相关的每个请求之间的状态。在一些情况下，例如运行在服务器上的静态HTML页或被存 储的媒体文件例如存储在服务器上的mp3或wav文件的情况下，步骤S7可被简化，且通过URI映射到磁盘的文件可被简单地返回。
[0061]步骤S9陈述了来自服务器的响应。这个响应优选地是HTTP响应。响应优选地作为XML、音频二进制或原始文本被发送，但也可以可选地是任何种类的消息发送格式，包括HTML、界定文本、键/值文本或二进制编码格式。HTTP响应优选地包括执行电话操作的指示。响应可以可选地或另外地包括新的URI和新的URI模板以与步骤S3中的电话操作一起使用。另外的示例性XML响应在图5A和图5B中示出。
[0062]1B.处理电话指令
[0063]用呼叫路由器处理电话指令的步骤S120优选地起作用，以将服务器响应转换为电话操作或在电话会话期间可执行的操作。电话操作可包括例如在服务器指定的URI (例如位于http://demo, twil1.com/myapp/1234.mp3的静杰mp3文件)播方文预先录制的声音文件、使用文本转语音技术为呼叫者读文本、呼叫另一个号码(例如通过PSTN、SIP/VOIP或其他的IP技术系统创建新的语音连接)、通过DTMF输入收集数字、记录语音响应音频、TTY或其他的数据、发送SMS消息、或者这些或其他的适当的操作的任何适当的组合或顺序。服务器响应的这个转换优选地在呼叫路由器上执行。优选地，步骤S120包括处理于服务器响应相关联的响应mime-类型。例如，如果响应mime-类型是XML，其被认为是一组呼叫路由器指令。如果响应mime-类型是MP3，其被认为是为呼叫者播放的声音文件。如果响应类型是纯文本，其被认为是通过文本转语音技术读给呼叫者的文本。
[0064]服务器响应的内容例如XML文档优选地通过顺序地(例如，逐行地)处理文档的方式被转换为电话操作。电话指令优选地以标记语言例如图5A和图5B中所示出的XML的形式被包含在文档中。处理电话指令的文档的这个连续的方式在通信是无状态且所有必要的信息都包含在URI中时有效。这个无状态通信优选地允许电话指令(动词或命令)被用作服务器应用用于执行电话服务的编程接口。电话动词或文档的(基于通信状态的)算法转换优选地为不必要的。优选地，按照服务器响应的内容中含有的电话指令的顺序来执行电话操作。例如，XML文档可包括必要的动词以实现为呼叫者读文本、监控由呼叫者按下的键、以及使用被按下的键作为新的URI的数据的部分来将呼叫者重定向到新的URI的电话操作。优选地，电话操作(例如被按下的数字)产生新的状态信息，这可导致方法的一些步骤的重复，优选地从步骤S3开始重复。下一个URI优选地由服务器提供作为处理指令的部分。在另一个变动形式中，如果服务器未能指定下一个URI则重复使用上一个URI。在又另一个变动形式中，如果服务器未能指定下一个URI则不发生重复，且过程向下进行下一个呼叫文本路由器指令。可通过呼叫路由器指令的性质确定行为；例如，没有产生新的状态信息的指令可能不需要有下一个URI，因为他们不触发与远程服务器的通信。更加优选地，电话操作导致步骤S3利用从步骤Sll得到的新的URI进行重复，但是可以可选地启动方法的一个或多个步骤(步骤S5、S7、S9或Sll)的重复。步骤S3优选地使用由执行电话操作产生的所有新的电话会话状态信息例如被按下的数字、录制的音频文件或被请求的任何电话操作的成功或失败信息来重复。重复还包括在会话期间保持相关的所有状态信息，例如呼叫者、被呼叫者、唯一呼叫ID和呼叫状态。状态信息还可以URI模板的形式表示。例如，如果服务器响应指定呼叫路由器收集DTMF数据，并指定下一个URL是URI模板http: //demo,twil1.com/fo0.php ? digits = {Digits}，且呼叫者按下 1234，得到的 URI 是 http://dem0.twil1.com/fo0.php? digits = 1234。类似地，如果服务器响应指定URI模板:http://demo, twil1.com/myapp/ {Digits}.mp3，所得到的 HTTP 请求可能是位于:http://demo, twil1.com/myapp/1234.mp3的静态mp3文件。因此，呼叫可由发出电话指令的服务器和处理响应的第二个服务器控制，如图13和图14中所示。这样的呼叫控制转接构成了状态信息以URI和附带的请求数据例如GET、POST和/或请求体的形式在服务器之间的转换。可选地，所有的状态通信遵循由呼叫路由器建立的句法，以促进多个服务器之间的集成。例如，在键盘上按下的数字优选地以相同的形式被传送到应用服务器，因此使对在多个应用服务器之间关于状态如何转换的协作的需要最小化。可选地，呼叫路由器指令可规定传递新的状态信息例如变量的名字和类型的方法，以发送代表性的新的状态。
[0065]1C.创建可由呼叫路由器API访问的资源
[0066]创建可通过应用程序接口(API)访问的呼叫路由器资源的步骤S130优选地起作用，以暴露呼叫路由器的信息和/或功能。来自外部多方的交互优选地通过API (呼叫路由器API)执行。呼叫路由器API可另外地与电话指令的使用协作，以作为对于由呼叫路由器的操作生成的或需要的数据的存储和取回格式而起作用。呼叫路由器API优选地是应用程序接口(API)，例如本领域中所知的REST API (表述性状态转移)，但是呼叫路由器API可以可选地是SOAP(简单对象访问协议)API或任何适当的编程式通信接口。呼叫路由器API优选地可由应用异步地用于执行呼叫(以便在以后查询呼叫记录或取回记录)。可选地，呼叫路由器API可在呼叫的过程中同步使用(例如改变呼叫状态、挂断呼叫、启动呼叫记录等)。呼叫路由器API优选地将状态信息存储在资源的持久URI中。持久URI优选地包含所有的必要的状态信息，且这优选地使得数据稳定、可查询且可恢复。呼叫路由器API优选地用于修改资源以改变呼叫路由器的状态并用于与呼叫路由器的媒体交互。应用服务器可使用呼叫路由器API，以优选地查询呼叫记录的元数据、呼叫者身份、呼叫媒体(例如记录、文本副本等)、账户信息、呼叫路由器中的转移或与正在进行的通信的交互、和/或操作呼叫路由器生成的或需要的任何适当的数据。呼叫路由器API优选地涉及应用服务器和呼叫路由器之间的通信，但是可以可选地是从任何适当的设备到呼叫路由器的通信。呼叫路由器API优选地存在于与呼叫路由器相同的硬件上，但也可以可选地存在于远程硬件或任何适当的硬件环境中。通信优选地为HTTP，但是可选地可使用HTTPS或任何适当的通信协议。另外，呼叫路由器API还可与任何HTTP客户端兼容。优选的实施方式的电话系统优选地实现包括呼叫路由器API请求格式、呼叫路由器API响应格式以及代表由呼叫路由器生成或使用的数据的类型的多个API资源的呼叫路由器API。
[0067]优选的实施方式的呼叫路由器API请求作为从应用服务器发送到呼叫路由器的API资源的通信消息起作用。呼叫路由器API请求优选地从应用服务器发送到呼叫路由器，但是也可从任何适当的设备发送到呼叫路由器。呼叫路由器API请求优选地类似于RESTAPI请求，但是呼叫路由器API请求可以可选地遵循任何适当地程序设计，例如SOAP。呼叫路由器API请求优选地使用HTTP与资源交互，但是也可使用HTTP或任何适当的通信协议。优选地，GET的HTTP或HTTPS方法用于取回资源或资源信息，且PUT或POST的HTTP或HTTPS方法用于创建或更新资源。在一些情况下，PUT或POST可用于通过修改资源的状态来影响呼叫路由器的功能。可选地，方法参数可包括在资源的URI中，以识别对于资源的被请求的操作，或者也可使用任何适当的命令或方法来与API资源进行交互。优选地，通过在URI中包括消息认证信息例如使用共用密钥的请求内容的加密散列，或通过任何适当的方法，呼叫路由器API请求包括认证例如基本的HTTP或HTTPS认证。
[0068]优选的实施方式的呼叫路由器API响应作为响应于在API资源上执行的方法而发送的通信信息来起作用。呼叫路由器API响应优选地从呼叫路由器发送到应用服务器或任何适当的设备。呼叫路由器API响应优选地响应于呼叫路由器API请求而发送，且响应优选地被发送到始发设备。呼叫路由器API响应优选地与REST API响应相似，该响应代表所请求的资源。呼叫路由器API响应可以可选地遵循任何适当的程序设计例如SOAP。呼叫路由器API响应优选地作为格式化XML而被返回，该格式化XML带有与HTTP状态代码对应的信息、消息、错误代码和/或与资源相关的任何适当的信息。呼叫路由器API响应可以可选地被表示为逗号分隔值列表(CSV)、HTML、JSON或任何适当的形式。在一个变动形式中，响应格式由所请求的URI的一部分例如文件扩展来确定。在一个变动形式中，API资源可以是二进制数据资源，且呼叫路由器API响应优选地被格式化为本机二进制格式(例如，wav或mp3音频文件)、XML元数据描述和/或任何适当的格式。
[0069]优选的实施方式的API资源作为呼叫路由器元数据、内部呼叫路由器状态、或由呼叫路由器使用的给定资源的状态的可寻址表示而起作用。优选地，API资源由持久URI寻址。优选地，API资源响应于POST、PUT、GET或DELETE的至少一个HTTP操作。API资源可以可选地响应于多个HTTP操作。API资源可以可选地响应于优选地包括在呼叫路由器API请求中的任何适当的方法。与RESTful惯例一致，资源的GET请求可返回资源的当前状态，而PUT可更新状态，PUT或POST可用于创建新的资源，DELETE可用于破坏资源。呼叫路由器API除了修改数据外还可以可选地用于影响正在进行的呼叫的功能。优选的实施方式的API资源包括账户资源、呼叫者ID资源、呼入的地址资源、呼叫资源、媒体资源和/或呼叫路由器的任何适当的资源。API资源可以可选地为所列出的资源或其他的适当的资源的任何适当的组合。API资源优选地是预配置(或者“静态”)资源，例如账户信息，或由呼叫路由器使用的活动状态的资源例如电话呼叫。通过API修改资源状态另外还可以实时地影响呼叫路由器的操作，影响呼叫路由器在将来的呼叫状态或能力，和/或具有任何适当的影响。
[0070 ]优选的实施方式的账户资源起作用，以允许应用取回和/或修改账户信息。账户优选地由电话服务器提供者例如呼叫路由器的操作者创建。例如账户名字、使用信息、联系信息、初始UR1、设置参数的信息或任何适当的账户信息可由应用使用账户资源来取回或编辑。
[0071]优选的实施方式的呼叫者ID资源起作用，以允许应用取回、修改、注册新的呼叫者ID(电话号码)、和/或删除呼叫者身份信息。优选地，呼叫者身份信息是针对于与由应用和/或用户(即，显示为发出呼叫的应用)进行的向外的呼叫相关的电话号码的。对于向外的呼叫的号码优选地在被用作呼叫者ID之前被分配和验证。作为可选方式，为了防止应用中的呼叫者ID电话号码被冒用，可在增加新的呼叫者ID资源之前由API使用验证步骤。增加呼叫者ID的请求可通过请求被始发到API，其中随机校验码被产生并在API响应中返回。校验码优选地被提供到终端用户。向所给的电话号码(呼叫者ID)进行电话呼叫，以请求通过键盘数字或口头输入检验码。在请求的时候，检验码的输入验证电话号码的所属或者与电话号码相关联的设备。呼叫者ID资源的使用还可通过显示检验码的方式在用户界面例如网络浏览器上呈现。用户接口可由呼叫路由器的操作者提供，或可由任何适当的应用使用API来提供。可将任何适当的方法用于呼叫者ID的验证。在呼叫涉及到多方的另一个可选方式中，可在那个呼叫会话期间为另外的向外呼叫分配一个现有方成员的呼叫者ID。
[0072]优选的实施方式的呼入的地址资源起作用，以允许应用获得、修改或提供新的向内DID电话号码、SMS短码、SIP地址等以用于应用。PUT或POST可用于设置与向内地址相关联的初始URI。DELETE可用于释放资源。呼入地址资源可用于电话号码或其他的可寻址向内标识符的实时提供。
[0073]优选的实施方式的呼叫资源起作用，以允许应用获得或修改呼叫路由器中的电话会话的状态。电话会话或呼叫可以是正在进行中、已完成、失败、未启动、和/或处于任何适当的呼叫状态。呼叫资源优选地可改变正在进行的呼叫的状态或连接。状态改变优选地包括:挂断或终止现有的电话会话、将一个或多个现有的电话会话从会话的一个环境组转移到另一个、合并或拆分现有组电话会话、将一个或多个电话会话从一个通信媒体转移到另一个(例如从一个URI转移到第二个URI)、将事件或通知引入到现有的会话或会话组、记录或停止记录来自呼叫的一方或多方的音频、和/或任何适当的呼叫操作。呼叫信息或呼叫日志数据优选地可通过发送GET到呼叫资源或可选地通过发送任何适当的方法来取回。向外的呼叫还可通过使用POST或优选地表明新的呼叫资源被创建的任何适当的方法来启动。当使用呼叫资源来启动呼叫时，可按需要提供信息以进行电话呼叫，该信息为例如要呈现的呼叫者ID、要呼叫的电话号码、和/或用于处理呼叫的URI，但是可选地可提供任何适当的信息。可选地，呼叫指令XML文档可代替URI被提供到API，其用于呼叫指令。例如当呼叫被应答时、当机器应答电话时、忙信号、无应答、呼叫失败和/或在任何适当的呼叫状态时，呼叫路由器API也可另外用呼叫的状态作出响应。可选地，该响应可表明新的呼叫请求已被接受但尚未启动。在图6中示出的例子中，呼叫者信息和呼叫者ID包括在向呼叫资源的POST请求中。这个步骤可能启动向呼叫信息中指定的电话号码的向外呼叫。呼叫路由器API响应包括与呼叫有关的有效状态信息，例如呼叫是否已经开始、呼叫开始时间、结束时间、价格、呼叫者信息，且可选地，呼叫路由器API响应可包括任何适当的信息。另外，由API在任何时间点返回的与呼叫有关的信息可取决于呼叫的状态。例如，如果呼叫尚未开始，则呼叫开始时间可不被给出，如果呼叫尚未结束，则呼叫结束时间、持续时间或价格可不被给出。
[0074]另外地或可选地，优选的实施方式的呼叫资源可用于通过单个呼叫资源接收POST、PUT和/或任何适当的方法来将呼叫转移到新的URI。在这种可选方式中，呼叫可选地被转移到对于新的呼叫指令的新的URI。优选地，API可用于引发呼叫状态的异步的改变，这与呼叫路由器和应用服务器之间的用于同步URI请求和响应的同步通信不同。在这种可选方式中，呼叫资源起作用以允许呼叫被异步地指向到多个URI。呼叫资源的各种应用的例子包括启动新的电话会话、终止现有的电话会话、呼叫等待、呼叫保持、呼叫排队、呼叫驻留、会议内的专有呼叫会话、多个呼叫会话的进行、和/或任何适当的应用。异步事件影响呼叫状态的任何情况例如呼叫代理变为有效，或在将呼叫者置于保持状态后有人回复电话。在请求所提供的URI之前，可允许完成或可立即终止当前执行的呼叫路由器指令。由呼叫路由器执行的上一个呼叫指令得到的新的呼叫状态，例如键盘上被按下的数字或被记录的来自呼叫者的音频，可以通过POST或GET参数的形式被提供给新的URI，或可以可选地被呼叫路由器丢弃并不被提供。如图15中所示出，呼叫等待可通过由应用发送呼叫路由API请求到为呼叫POST新的URI的呼叫资源的方式来实现。然后呼叫者被指向到指令的新的URI。第二个呼叫路由器API请求被发送到为呼叫POST始发URI的呼叫资源，且因此使呼叫者回到第一个呼叫会话。呼叫资源可以可选地用于任何适当的应用中。
[0075]作为呼叫资源的可选的实施方式，呼叫资源可实现多个独立呼叫作为不同的子资源。例如，以“/Calls”结尾的URI可以是由账户执行的一系列多个呼叫，以“/Calls/12345”结尾的URI可代表由密钥“12345”唯一识别的一个指定的呼叫。呼叫资源优选地允许取回很多呼叫记录和/或创建新的呼叫，而单个呼叫资源代表单个呼叫。呼叫资源优选地接受创建新呼叫资源的请求，如在RESTful结构中所常见的，其在呼叫路由器API中，优选地用来启动一个或多个新呼叫。呼叫资源可用于使用GET方法列出当前的和先前的呼叫，以及使用POST方法启动新的向外呼叫。使用RESTful原理例如POST或PUT来改变独立呼叫资源的状态可以可选地例如通过挂断、将控制转移到新的UR1、将呼叫与另一个呼叫接合或以任何适当的电话操作的方式来改变正在进行的呼叫的状态、影响呼叫的实时操作。
[0076]优选的实施方式的媒体资源起作用，以允许应用取回和/或访问在呼叫过程中所存储、取出、创建和/或使用的媒体的信息。在一个变动形式中，媒体资源优选地是记录资源，以访问信息以及在呼叫期间通过记录呼叫指令或异步地通过呼叫路由器API而作出的记录。在另一个变动形式中，媒体资源可以可选地包括呼叫副本、文本消息、按键日志、传真、二进制码资源和/或任何适当的媒体。媒体资源可以可选地包括二进制码文件(例如wav、mp3音频文件或PDF文档文件)的URI。在一个变动形式中，媒体资源还可与电话指令(或标记语言)合并，以使得电话指令可指示呼叫路由器执行创建媒体资源的操作。呼叫路由器优选地以所创建的媒体资源的URI发送响应到应用服务器。例如，当呼叫路由器被指示记录消息时，呼叫路由器优选地以API中所记录的消息的唯一 URI发送响应到应用服务器。媒体URI优选地响应GET请求以返回多种格式的媒体，例如二进制或XML元数据表示。媒体资源可接受删除媒体资源的请求。在一个变动形式中，媒体资源优选地需要访问资源的认证。在另一个变动形式中，媒体资源可不需要使URI能够嵌入多个应用的认证，也就不暴露认证凭证。在又一个变动形式中，认证优选地通过加密散列来执行，以使得凭证不被暴露给消费媒体资源的客户端应用。在另一个变动形式中，媒体资源允许使用转录技术启动音频资源向文本的转录。用于转录的音频资源优选地在电话会话期间产生(例如通过记录指令)并以呼叫路由器API为主机。媒体资源优选地允许取回或删除由所记录的媒体生成的音频转录。媒体资源还可允许集中控制媒体文件，且资源URI优选地在呼叫路由器和应用服务器之间而不是在大媒体文件自身之间交换。媒体资源可以可选地用于任何适当的媒体。
[0077]另外地或可选地，优选的实施方式的接合资源可用于将一个或多个呼叫接合到共享会话中，其允许多方通过单个呼叫资源接收P0ST、PUT的方式和/或通过任何适当的方法来通信(即，进行会议)。在这个可选方式中，优选地，一个或多个呼叫接合到一起以使得它们在一个会议中。接合资源可以可选地是子资源或呼叫资源的部分。
[0078]另外地或可选地，优选的实施方式的拆分资源可用于通过单个呼叫资源接收POST,PUT的方式和/或通过任何适当的方法将共享的会话(例如，会议)拆分为独立的呼叫会话。在这个可选方式中，涉及两个或多个呼叫的一个或多个共享会话优选地被拆分，以使得一个或多个呼叫被拆分成多个分离的呼叫或拆分成一个或多个分离的会议。拆分资源可以可选地是子资源或呼叫资源的部分。
[0079]2.用于处理电话会话的系统
[0080]如图2A、2B、3A和3B中所示，用于处理电话会话的优选的实施方式的系统20和30包括呼叫路由器22、应用服务器的URI 23、电话指令27，以及呼叫路由器资源29。如图2A和2B中所示，第一设置20由电话设备(例如电话呼叫、传真或SMS消息)启动。如图3A和3B中所示，第二设置30由应用开发者侧(即，呼出的服务器26)启动。优选的实施方式的电话系统优选地还实现呼叫路由器API 28，其包括呼叫路由器API请求格式、呼叫路由器API响应格式和实质上与以上描述的那些资源类似的多个资源。
[0081]呼叫路由器22起作用以启动呼叫或从电话设备接收呼叫并连接到网络应用服务器。呼叫路由器22优选地通过PSTN网络连接到PSTN设备，以使得其可从PSTN连接的设备21以及非PSTN设备接收呼叫和进行呼叫，PSTN连接的设备例如固定电话、蜂窝电话、卫星电话、或任何其他的适当的PSTN连接的设备，非PSTN设备例如网络语音(VOIP)电话、SIP设备、Skype、Gtalk、或其他的互联网可寻址语音设备。呼叫路由器22可以可选地或另外地作为用于SMS消息的消息路由器起作用或包括用于SMS消息的消息路由器。呼叫路由器22可以优选地连接到SMS网络，以使得其可从SMS网络设备21、蜂窝电话、计算机、智能电话或任何适当的SMS网络设备接收消息和发送消息。呼叫路由器22还可发送或接收文本消息、多媒体消息、电子邮件、传真和其他适当的可PSTN兼容的通信消息。呼叫路由器2 2优选地使用应用层协议与应用服务器26通信，更加优选地使用HTTP协议或安全HTTPS协议与应用服务器26通信。应用服务器26和呼叫路由器22之间的通信优选地是无状态的通信，且任何状态信息(例如呼叫状态)或数据优选地位于URI或请求参数中，例如HTTP报头、GETURI参数、POST请求体参数或HTTP cookies中。有效的状态信息优选地由呼叫路由器请求发送到应用服务器以用于无状态处理，且应用服务器优选地不存储状态。可选地，应用服务器优选地存储网络开发中常见的本地状态信息，例如数据库或会话。呼叫路由器22优选地存储状态信息在呼叫路由器资源29中。呼叫路由器资源29优选地由应用服务器26和其他设备通过呼叫路由器API 28访问。呼叫路由器资源29优选地与以上描述的那些资源相似。呼叫路由器22优选地将每个呼入电话号码与起始URI 23相关联，更加优选地，URI 23由应用服务器26提供，又更加优选地，在呼叫路由器22接收到呼叫之前，URI 23由应用开发者通过将初始URI与呼入呼叫地址(例如DID、SIP地址等)相关联的方式提供，或在启动向外呼叫时由应用来提供。呼叫路由器22优选地发送呼叫数据例如(通过呼叫者ID获取的)呼叫者号码、呼叫者地理数据(国家、城市和/或州、邮编)、被拨叫号码、呼叫的时间、或任何其他的适当的信息或参数。呼叫数据优选地用存储在呼叫路由器22上的密钥25进行数字签名。信息的加密散列优选地连同该信息一起被包括作为数字签名。呼叫路由器22还可(在加密散列被计算之前或者之后)使用密钥加密敏感信息，以允许敏感信息通过网络被发送。呼叫数据优选地作为HTTP POST请求被发送到应用服务器26。呼叫数据还可在URL(GET)变量中被发送，或被封装在HTTP报头中。在图4A和4D中示出包含报头中的信息的示例性HTTP请求。如图4B中示出，来自PSTN设备的进一步的输入(例如语音记录或按DTMF按钮)可作为HTTP请求(GET或POST)被接连地提交到应用服务器26。如图4C中所示出，来自电话键盘的输入可包括在HTTP GET请求中。如图4E中示出，由呼叫路由器接收的SMS消息内容可作为HTTP请求被发送到应用服务器26。如图4F中示出，来自下一条消息的输入包括在HTTP GET请求中。请求数据可以可选地在URL (查询字符串)、消息体(POST)和消息报头或以上的任意组合中同时发送。
[0082]应用服务器26起作用，以为从呼叫路由器22接收的请求提供数据处理逻辑。应用服务器26优选地通过网络24、更加优选地通过互联网连接到呼叫路由器22。应用服务器26优选地是在系统外部操作的第三方服务器，但是该系统可以可选地包括应用服务器26。URI 23优选地与应用服务器26或应用服务器26上的应用相关联。应用服务器26优选地使用应用层协议、更加优选地使用HTTP协议或更加安全的HTTP协议与呼叫路由器22通信。应用服务器26优选地从呼叫路由器22接收HTTP请求或发送HTTP请求到呼叫路由器22。应用服务器26优选地在编程语言、主控提供者、操作系统和数据库的标准栈上运行，以处理HTTP请求，如同呼叫者是网络浏览器中的网站访问者一样。应用服务器26可优选地使用密钥来验证在请求中接收到的呼叫数据的数字签名，以从所接收到的信息和所接收到的散列来计算加密散列。如果所计算的散列和所接收的散列不匹配，或没有接收到请求中的散列，那么应用服务器26优选地确定该请求为假，且优选地，该请求被丢弃。如果所计算的散列和所接收的散列匹配，则应用服务器26优选地确定请求是真实的，并进一步进行对请求的处理。如果安全不重要，则应用服务器可以可选地选择忽略散列。应用服务器优选地使用由呼叫路由器请求传送的呼叫状态数据来确定下一个呼叫路由器指令，而不需要存储在应用服务器上的呼叫状态。应用服务器可以可选地使用由呼叫路由器发送的呼叫状态数据，例如呼叫者的呼叫者ID或呼叫的唯一 ID，以参考另外的或外部的状态数据，例如数据库中的行或存储在应用服务器上的会话数据。应用服务器26优选地通过产生对于呼叫路由器22的电话指令27，来响应从呼叫路由器22接收的HTTP请求。应用服务器优选地以XML回复呼叫路由器，但是，也可使用任何适当的机器可读的消息格式，包括HTML、键/值对文本、界定文本或二进制编码。XML优选地包括对于呼叫路由器22的电话指令27，例如连接到另一个号码、播放已录制的问候、读文本、和/或请求呼叫者的DTMF数字输入。电话指令27可以可选地与SMS消息发送、多媒体消息服务(MMS)消息发送、电子邮件或任何适当的消息发送任务相关。电话指令27还可用于发送向外的SMS消息、排列来自具体电话号码的电话呼叫、安排回叫、建立会议呼叫(连接多个号码)、发送电子邮件、与日历或日程安排系统交互、购物、或服务、或任何其他适当的指令。XML指令优选地是按顺序每次执行一个(即顺序地执行)的一组命令。示例性的XML响应在图5A和5B中示出。在单个的电话会话(例如，由PSTN设备或SMS设备启动的电话会话)中，来自应用服务器的响应可启动向外的电话会叫和/或SMS消息。也就是说，单个的XML响应优选地提供与SMS网络和语音电话网络(PSTN、SIP、VoIP等)顺序地或同时地进行交互的能力。另外，被发送到呼叫路由器22的音频或视频文件可由自动语音转文本引擎、人工或其他技术转换为文本，并以文本形式作为SMS消息或MMS的附件被发送回。在一个变动形式中，运行在服务器上的应用可以是部署在没有可用的开发或编写脚本的环境的静态网络服务器上的简单的静态XML页和静态的声音文件。这个变动形式优选地使用URI模板(IETF目前推出的HTML5)，其基本包括带有可变数据的占位符的URL，如:http://www.twil1.com/aud1/{Digit}.mp3，其中呼叫路由器22将用按下的数字代替URI模板中{Digit}占位符，在得到的URI处GET文件，并播放静态声音文件作为响应。这允许整个应用在所见即所得(WYSIWYG)html编辑器中被离线编写。例如，如果服务器响应指定URI模板:http://dem0.twil1.com/myapp/{Digits}.mp3，呼叫者按数字 1234，呼叫路由器 22 将 GET 位于 http://demo, twil1.com/myapp/1234.mp3的静态mp3并将其播放给呼叫者。URI目标中用作替代的变量优选地与为来自呼叫路由器的HTTP GET、POST和/或报头请求中的状态提交而定义的变量的名字相对应。由先前的例子可知，{Digits}可与优选地作为“聚集”电话指令(DTMF数字的集合)的结果而产生的名称为“Digits”的参数相关联。在对于第二个设置的优选实施方式中，呼叫由应用服务器26 (通过呼叫路由器22)启动，且第二个设置30实质上与第一个设置20相似，以使得呼叫路由优选地被同样地处理到进入的呼叫，也就是当呼叫状态改变时通过从呼叫路由器22到服务器26的URI请求进行处理。应用服务器还优选地能够作出向呼叫路由器API的呼叫，如以上所述。
[0083]3.示例件应用
[0084]呼叫路由器应用优选地是网络应用，以实现具有用于管理的全API的最普通的电话系统特征。每个呼叫路由器应用对象具有唯一的URI。呼叫可通过指定其URI作为呼叫目标的方式被转移到那个对象实例。呼叫路由器应用优选地包括:AutoAttendant应用(在图7 中)、Follow Me 应用(在图 8 中)、Conference 应用(在图 9)中、Autoconference 应用(在图 9-11 中)、Device 应用、Person 应用、VoicemailBox 应用、Group 应用以及 Queuing应用(在图12中)。
[0085]如图7中例举的AutoAttendant应用播放已录制的问候，并等待呼叫者按键盘上的一个或多个数字。基于输入，AutoAttendant优选地将呼叫指向另一个AutoAttendant、人们的电话中的一个或多个、语音邮箱或任何其他的有效的呼叫目标。
[0086]如图8中例举的Follow Me应用使得能够用多个设备例如工作号码、蜂窝电话号码、固定电话和/或网络语音电话设备联系到人。Follow Me应用优选地按顺序地或同时呼叫这些设备，以试图联系到人。
[0087]Stay With Me应用使得人们能够在多个电话设备例如蜂窝电话和家庭电话之间转移正在进行的呼叫。例如，用户可能希望将呼叫从比较昂贵的蜂窝电话转移到不那么昂贵的固定电话上，或者，可能希望在蜂窝电话电池即将用尽时将呼叫转移到固定电话上。
[0088]图9中例举的Conference应用优选地允许三个或多个呼叫者同时参加呼叫，同时提供控制谁可在呼叫期间加入并说话的机制。Conference应用可以可选地或另外地合并SMS消息发送控制。当接收到包括多个电话号码的SMS消息时，Conference应用可使用单个SMS启动向一方或多方的会议呼叫。
[0089]AutoConference应用优选地允许会议管理者通过执行一个操作来启动与两方或多方的会议呼叫，该操作例如选择网站上的按钮、选择电话设备上的按钮、拨叫电话号码、或在其启动之前排定呼叫。使用本发明的优选的实施方式实现的AutoConference应用的例子在图9 (从PSTN设备侧观看)、图10 (从应用服务器侧观看)以及图11 (由使用呼叫路由器API的应用服务器启动)中示出。
[0090]Device应用表示在电话系统中使用的电话，且可以是硬电话(硬件)或软电话(软件)、VOIP电话或传统的PSTN电话。Device应用处理设置细节和设备状态(免打扰、忙碌等)。
[0091]Person应用表不电话系统的真人用户。Person可具有一个或多个分机、设备和/或语音邮箱，且可具有拨打他们的电话或语音邮箱的优选的顺序。人们可有用来登录和更新这些设置的用户名和口令。
[0092]VoicemailBox应用优选地播放问候，并允许呼叫者记录消息。当完成之后，已录制的消息可被存储以用于以后收听、可作为语音连接或附件或这两者被电子邮寄。可通过AP1、通过RSS源和/或任何其他的适当的方法或设备拨叫，取回对于语音 邮箱的一系列当前消息。在一个变动形式中，音频记录可被自动转录，将语音转换为文本。文本优选地连同音频链接、附件被包括在电子邮件或文本消息中，并/或可在以后由任何适当的API工具取回。
[0093]Group应用优选地表示其他的呼叫路由器应用对象的逻辑组，包括其他的组。组优选地限定被指向到组的呼叫的行为，包括排队、搜索第一个可用的被呼叫方，以及同时拨打多个被呼叫方。
[0094]当接收到电话呼叫或SMS消息时，Queuing应用优选地输入消息发送者到电话呼叫队列，且消息发送者通过PSTN、SIP/VoIP网络或其他的电话网络回呼，如图12中所例举的。当人/操作者/服务(客户服务应用)中任一项在预先安排的时间可用时，可进行对消息的始发号码或另一个预先制定的号码的呼叫，例如叫醒电话、周年纪念提醒、生日提醒。
[0095]呼叫路由器应用可另外地或可选地包括:
[0096]Busy Signal Buster服务，其在接收到SMS消息或电话呼叫时，发送要被呼叫的当前正忙碌的号码，并在该号码不再忙碌时以消息的始发号码或另一个预先制定的号码向SMS消息发送者回呼；
[0097]SMS Reader/TTY应用，其在接收到SMS时，使用文本转语音引擎为呼叫者或音频会议的成员将文本转换为音频(例如，告诉他们你们将在几分钟后加入呼叫)，或由听力受损者使用以取代TTY服务；
[0098]Translat1n应用，其在接收到包含某种语言的短语时，将SMS消息的语言(人工地或者由程序自动地)转换为另一种语言并通过SMS或电子邮件发送响应消息；以及
[0099]Programming应用，其在接收到包含编程代码的SMS消息时，可编译代码并执行代码、更新网站、更新编程项目、从数据库返回数据、作为MMS消息返回生成的计算机图形对象、或任何其他的适当的程序编译或计算。
[0100]呼叫路由器应用可另外地或可选地包括Status/Notificat1n应用，该应用允许用户通过经由PSTN、SIP/VoIP网络或其他电话网络发送SMS消息和接收回呼，获得或发送对象、任务或过程的状态。该服务可由发送带有特定服务器的名称的SMS消息的操作者使用，且然后获得在其移动电话上的回呼，并听到那个服务器的状态被出声地读出。该服务还可用于通知，即，用于呼叫其他的被叫方。例如，存储管理器可能需要让雇员知道存储器在第二天的什么时间开放。管理器可发送SMS消息，这将在随后呼叫每个雇员并通过电话告诉他或她存储器在第二天的什么时间开放以及/或他们需要在什么时间上班。
[0101]但是，呼叫路由器应用可包括这些或其他的适当的预建立的电话函数和特征的任何集合和/或排列。
[0102]优选的方法的应用可包括简单的PBX功能，例如自助语音菜单、雇员扩充以及语音邮件特征。应用还可包括其他的、非常规的应用例如Interactive Hold应用、ConferenceCalling 应用、Independent Music Hold Channel、Voting/Fundraising 应用、Sales 应用、Blog by phone 服务以及 Call Annotat1n 应用。
[0103]Interactive Hold应用优选地包括交互活动，例如在等候接听时进行答问比赛(具有或不具有与其他呼叫者竞争的能力)、收听新闻头条或听者的选择的语音播客，以及使用电话键盘作为合成器实时来创建音乐。作为例子，Conference Calling应用可包括从电话本中选择特定的(或随机的)用户并向组证实会议呼叫，具有保留所述组以用于将来的呼叫的能力。Independent Music Hold Channel优选地在呼叫者等候接听时允许独立的艺术家上载、分类他们的作品并准许播放他们的作品。Voting/Fundraising应用优选地将有意愿的呼叫者(呼叫以鼓励投票或为事业筹集资金的呼叫者)分别连接到潜在的投票者和/或捐赠者，优选地包括呼叫者用于显示与投票者/捐赠者有关的信息的接口，并记录关于投票者对呼叫的反应。Sales应用优选地允许销售组织快速地将向内的和向外的呼叫与客户关系管理(CRM)应用集成，或从购物车应用读订单详细信息。最后，Call Annotat1n应用允许呼叫参与者附加元数据，例如电话交谈中使用的参考URI，以指定呼叫和呼叫中的时间戳。有适当的用户代理的呼叫的参与者可在呼叫期间查看注释，听呼叫音频的后来的重播的人还可在回放期间以相同的时间戳接收这样的注释。Call Annotat1n可用于例如促进会议呼叫记录的进行、雇员培训、销售团队合作和/或顾客支持合作。
[0104]应用可以可选地包括保持或驻留功能，其中呼叫者处于等待状态直到外部的事件恢复呼叫，例如另一方变为有效。这个应用的一个变动形式是呼叫队列，其中呼叫者等待有效的服务人员应答呼叫。优选的方法的应用可以可选地包括其他的传统的或非传统的PBX功能。
[0105]本领域中的技术人员将从先前的详细描述以及从附图和权利要求中认识到，可对本发明的优选的实施方式作出修改和改变而不偏离以下的权利要求所限定的本发明的范围。可能地并确实有希望地，基于本技术平台(本发明的优选的方法和/或系统)设计和建立以其他方式的可能不使用传统的电话平台的另外的应用。
【主权项】
1.一种用于处理电话通信的方法，包括: 将初始URI与电话端点相关联； 启动用于到所述电话端点的电话通信的电话语音会话； 将所述初始URI映射到所述电话语音会话； 将应用层协议请求发送到由所述URI指定的应用资源，并且将所述电话语音会话的状态信息嵌入到所述请求中； 接收发送到所述应用资源的所述应用层协议请求的响应，其中所述响应包括电话指令的文档；以及 根据对所述响应的所述电话指令的至少一个子集的顺序处理，在所述电话语音会话期间执行电话操作。2.如权利要求1所述的方法，其中所述电话通信是呼叫。3.如权利要求2所述的方法，其中，执行电话操作包括通过公用交换电话网络PSTN进行通信。4.如权利要求1所述的方法，其中，执行电话操作包括在所述电话语音会话期间进行以下电话操作:播放音频、播放文本到语音的视频，捕获输入、呼叫电话端点或录制音频。5.如权利要求1所述的方法，其中执行电话操作包括发送电话消息，所述电话消息被发送到电话端点。6.如权利要求5所述的方法，其中，发送所述电话消息包括通过七号信令系统SS7的网络进行通?目。7.如权利要求5所述的方法，其中所述电话消息是短消息服务SMS消息和多媒体消息服务MMS消息中的至少一个。8.如权利要求1所述的方法，其中所述电话端点是电话号码和会话启动协议SIP地址中的至少一个。9.如权利要求1所述的方法，其中，启动用于到所述电话端点的电话通信的电话语音会话响应于向内电话通信。10.如权利要求1所述的方法，其中，启动用于到所述电话端点的电话通信的电话语音会话响应于应用程序接口请求以创建电话通信。11.如权利要求1所述的方法，其中，执行用于所述电话语音会话的电话操作包含在所述电话语音会话期间重定向到第二 URI。12.如权利要求11所述的方法，还包括:将应用层协议请求发送到由所述第二URI指定的第二应用资源；从所述第二应用资源接收第二响应，其中所述第二响应包括电话指令的第二文档；以及，根据所述第二响应的顺序处理的电话指令，执行用于所述电话语音会话的电话操作。13.如权利要求12所述的方法，其中所述电话语音会话的状态被嵌入在所述第二URI中。14.如权利要求13所述的方法，其中，收集的数字被嵌入在所述第二URI中。15.如权利要求1所述的方法，其中，执行电话操作包括处理所述响应的互联网内容类型及基于所述互联网内容类型确定电话操作。16.如权利要求15所述的方法，其中，处理所述互联网内容类型包括:如果所述响应包括电话指令的文档，则将内容类型设为第一类型，且如果所述响应是可播放的媒体文件，则将内容类型设为第二类型；并且其中执行所述电话指令包含:如果所述响应是第一类型，则在呼叫路由器处顺序地处理所述电话指令，且如果所述响应是第二类型，则在呼叫路由器处播放所述可播放的媒体文件。17.如权利要求16所述的方法，其中，包括无状态电话指令的可扩展标记语言文档的响应是第一类型，且包括音频文件的响应是第二类型。18.如权利要求1所述的方法，其中，所述状态信息至少包括初始电话端点、目标电话端点以及电话语音会话标识符。19.如权利要求1所述的方法，其中，根据所述响应在所述电话语音会话期间执行电话操作在呼叫路由器处无状态地执行。20.如权利要求1所述的方法，其中，执行电话操作包括:根据指定第二URI的电话指令，重定向到所述第二 URI ;其中重定向包含将应用层协议请求发送到由所述第二 URI指定的第二应用资源及将所述电话语音会话的状态信息嵌入所述请求中；接收所述第二应用资源的响应；以及根据所述第二应用资源的响应在所述电话语音会话期间执行电话操作。
【专利摘要】本发明涉及处理电话会话的系统和方法。在一个实施方式中，处理电话会话的方法包括：使用应用层协议与应用服务器通信；用呼叫路由器处理电话指令；以及创建可通过呼叫路由器应用程序接口(API)访问的呼叫路由器资源。在另一个实施方式中，用于处理电话的系统包括：呼叫路由器、用于应用服务器的URI、由呼叫路由器执行的电话指令、以及呼叫路由器API资源。
【IPC分类】H04M7/00
【公开号】CN104902113
【申请号】CN201510204607
【发明人】杰弗里·劳森, 约翰·沃尔斯, 埃文·库克
【申请人】特维里奥公司
【公开日】2015年9月9日
【申请日】2009年4月2日
【公告号】CA2720398A1, CN102027721A, CN102027721B, EP2266269A1, EP2266269A4, US8306021, US8611338, US8755376, US20090252159, US20100142516, US20130028251, US20130128882, US20140098809, WO2009124223A1
【专利说明】处理电话会话的系统和方法
[0001]本申请是申请日为2009年04月02日，申请号为200980116961.6，发明名称为“处理电话会话的系统和方法”的申请的分案申请。
[0002]相关申请的交叉引用
[0003]本申请要求以下专利申请的利益:于2008年4月2日递交的名称为“System andMethod for Processing Telephony Sess1ns” 的申请号为 61/041，829 的美国临时申请;于 2008 年 5 月 22 日递交的名称为“System and Method for Processing SMS Messages”的申请号为61/055,417的美国临时申请，于2008年9月26日递交的名称为“System andMethod for Processing Telephony Sess1ns” 的申请号为 61/100，578 的美国临时申请，于2009年3月2日递交的申请号为61/156，746的名称为“System and Method forProcessing Telephone Sess1ns”的美国临时申请，以及于2009年3月2日递交的申请号为 61/156，751 的名称为“System and Method for Processing Telephony Sess1ns” 的美国临时申请，以上所有申请的全部内容通过引用并入本文。
技术领域
[0004]本发明一般涉及电话领域，且更具体地涉及用于处理电话领域内的电话会话的新的和有用的系统和方法。
【背景技术】
[0005]在最近十年，网络语音电话(VOIP)的出现和立法以新的技术、商业模式和服务提供者革新了通信行业。软件和商用硬件现在提供了昂贵的载体设备的替代物。人们可在开放源软件应用(例如Asterisk和FreeSwitch)中实现可扩展呼叫转换和语音应用逻辑。但是，这些新的应用的堆积引发了新的复杂性和挑战，需要新的技术组来部署、开发和维持。部署电话服务需要语音网络和编解码器、硬件或服务的知识，以连接服务器与共用电话基础设施、对硬件以及这硬件的持续配置进行资本投资。这些负担只是开发实际应用的先决条件，其需要开发者进行新的语音、工具和开发环境的培训。即使是当前试图将模型调整为与网络开发例如语音可扩展标记语言(VoiceXML)更加相似的电话应用，也需要致力于学习新语言和理解电话交互。这些服务的持续操作和维护需要团队采用新的分析工具、性能标准和调试方法。即使是开发最简单的语音服务(例如所谓的“电话树”)也需要对专门的基础设施、技术和操作进行大量的前期和持续的投资。因此，在电话领域中需要用于处理电话会话的新的和有用的系统。本发明提供了这样的新的和有用的系统和方法。
【发明内容】
[0006]用于处理电话会话的优选的实施方式的方法包括使用应用层协议与应用服务器通信、用呼叫路由器处理电话指令、以及创建可通过应用程序接口(API)访问的呼叫路由器资源的步骤。优选的实施方式的方法和系统使网络开发者能够在电话的神秘世界里使用他们现有的技术和工具，像网络编程一样容易地进行电话应用开发。方法和系统使用熟悉的网站访问者模式与网络开发者的应用交互，其中电话呼叫的每个步骤与传统的页面浏览相似。在这种模式中，开发者重新利用他们现有的工具和技术，包括熟悉的概念例如HTTP重定向、通过AP1、cookie和mime类型响应访问资源以构建复杂的电话应用。处理电话指令和创建可通过API (呼叫路由器API)访问的呼叫路由器资源的方法协同起作用，以利用多个呼叫路由器资源以及通过呼叫路由器(优选地为很多网络开发者熟悉的REST API)提供的信息来使能无状态(stateless)和简单电话语言。在一个实施方式中，电话指令组可具有少于十来个的动词用于简化语言，以使得开发者可快速地学习和实现电话应用，同时呼叫路由器API完善简单的电话指令以使能复杂的电话应用。
[0007]本发明提供了一种处理网络的电话会话的方法，所述网络包括应用服务器和呼叫路由器，所述方法包括以下步骤:
[0008]使用应用层协议与所述应用服务器通信；
[0009]用所述呼叫路由器处理电话指令；以及
[0010]创建可通过呼叫路由器应用程序接口(API)访问的呼叫路由器资源。
[0011]所述方法还可包括将电话会话映射到统一资源标识符(URI)的步骤，其中所述URI可与所述应用服务器相关联。
[0012]所述方法还可包括将所述电话会话的状态信息嵌入到所述URI的步骤。
[0013]所述应用服务器所需要的所有状态信息可嵌入在所述URI中。
[0014]所述方法还可包括以下步骤:向所述应用服务器发送请求；将所述电话会话的状态信息嵌入到所述请求中；以及从所述应用服务器接收响应；其中所述响应包含所述电话指令。
[0015]发送的步骤和接收的步骤可以使用超文本传输协议(HTTP)来执行。
[0016]所述电话指令可以用可扩展标记语言(XML)编码。
[0017]所述方法还可包括利用所述请求发送数字签名的步骤，其中所述数字签名可适合于由所述应用服务器用于账户验证。
[0018]所述数字签名可以是由密钥生成的加密散列，其中所述密钥可以由呼叫路由器和所述服务器共用，且其中所述加密散列可包括在所述URI中。
[0019]所述方法还可包括顺序地处理电话指令的步骤。
[0020]所述方法还可包括通过公用交换电话网络(PSTN)从电话号码启动所述电话会话的步骤。
[0021 ] 所述方法还可包括由从短消息服务(SMS)系统接收的消息启动所述电话会话的步骤。
[0022]所述方法还可包括由应用服务器通过所述呼叫路由器API启动所述电话会话的步骤；其中映射到所述电话会话的初始URI可由所述应用服务器提供。
[0023]所述呼叫路由器资源可由可寻址URI处的外部设备访问。
[0024]所述呼叫路由器API实质上可以是表述性状态转移(REST)API。
[0025]所述方法可包括以下步骤:将状态信息存储在呼叫路由器资源的URI中；修改呼叫路由器资源以改变所述呼叫路由器的状态；以及根据所述呼叫路由器API而与所述呼叫路由器的媒体交互。
[0026]所述方法可包括以下步骤:从所述应用服务器接收API请求以与资源交互；以及基于与资源的所述交互而对API请求进行响应。
[0027]所述方法可包括创建从由呼叫资源、媒体资源、呼入地址资源、账户资源和呼叫者身份(ID)资源组成的组中选择的资源。
[0028]所述方法可包括:用所述呼叫资源改变所述电话会话的状态；用所述媒体资源访问媒体；用呼入地址资源修改呼入地址；用所述账户资源修改账户信息；以及用所述呼叫者ID资源修改呼叫者ID信息。
[0029]所述电话指令可从由以下项组成的组中选择:连接到电话设备、播放媒体文件、将文本转换为语音、检测来自电话设备的输入、以及连接到新的URI。
[0030]所述方法可包括创建呼叫资源；其中所述呼叫资源可用于改变所述电话会话的连接。
[0031]改变呼叫会话的连接可包括:加入电话会话、拆分电话会话、以及转移电话会话。
[0032]本发明还提供了一种处理电话会话的系统，包括:
[0033]呼叫路由器，该呼叫路由器连接到电话设备并使用应用层协议与应用服务器通Is ;
[0034]用于应用服务器的URI，该URI与电话地址相关联；
[0035]电话指令，该电话指令由所述呼叫路由器顺序地执行；以及
[0036]呼叫路由器API资源，该呼叫路由器API资源由所述呼叫路由器创建并可由所述应用服务器通过呼叫路由器API访问。
[0037]所述应用层协议可以是HTTP协议，且其中所述电话指令可用XML编码。
[0038]所述请求可封装呼叫的状态。
[0039]所述呼叫路由器API可以是REST API。
[0040]所述资源可从由呼叫资源、媒体资源、账户资源、呼入地址资源和呼叫者ID资源组成的组中选择。
【附图说明】
[0041]图1是本发明的优选的方法的流程图表示。
[0042]图2A、2B、3A和3B是本发明的优选的实施方式的示意图。
[0043]图4A-4C分别是HTTP GET请求、HTTP POST请求和HTTP GET请求的例子。
[0044]图4D-4F是HTTP请求的例子。
[0045]图5A和5B是XML响应的例子。
[0046]图6是呼叫路由器请求和响应的例子。
[0047]图7-15是包括本发明的优选的方法的原理的各种应用的示意图。
[0048]图16是与本发明的优选的方法的数字标记部分相关的子步骤的流程图表示。
【具体实施方式】
[0049]本发明的优选的实施方式的以下的描述不意味着将本发明限于这些优选的实施方式，而是意图使本领域任何技术人员能够实施和使用本发明。
[0050]1.用于处理电话会话的方法
[0051]如图1、2A、2B、3A和3B中所示出，用于处理电话会话的优选的实施方式的方法10包括使用应用层协议与应用服务器通信的步骤S110、用呼叫路由器处理电话指令的步骤S120、以及创建可通过应用程序接口(API)访问的呼叫路由器资源的步骤S130。优选的方法还可包括以下解释的其他步骤和/或子步骤。
[0052]1A.与应用服务器通信
[0053]如图1中所示，使用应用层协议与应用服务器通信的步骤SllO优选地包括以下子步骤:启动电话会话S1、将呼叫映射到统一资源标识符(URI) S3、发送请求到与URI相关联的服务器S5、处理与电话会话的状态对应的请求S7、以及从服务器接收响应S9。使用熟悉的网站访问者模式的一个挑战是第三方网络应用可能暴露包含敏感数据的URI或暗示可恶意操作应用数据库的行为 的URI。在优选的实施方式中，呼叫路由器使用账户指定密钥加密地签名向外发送到客户网络应用的请求。更具体地，与应用服务器通信的步骤包括数字地签名请求参数的另外步骤S4以及验证请求参数S6的数字签名的另外步骤S6。只有呼叫路由器和应用服务器知道所述密钥，所以包括用所述密钥签名的参数(URL、POST数据、报头等)的请求可在允许这样的操作之前被检查真实性。这个方法还用低CPU开销提供对安全链接(HTTP)的真实性验证。
[0054]陈述了启动电话会话的步骤SI起作用以接收进来的消息。该消息优选地是来自PSTN(公用交换电话网络)连接的设备或互联网可寻址设备的呼叫，例如固定电话、蜂窝电话、卫星电话、网络语音电话(VOIP)、SIP设备、Skype, Gtalk或任何其他的适当的PSTN连接的或互联网可寻址的语音设备。消息可以可选地是短消息服务(SMS)消息。SMS网关服务器可以可选地通过短消息服务中心(“SMS-C”)连接到SMS网络、直接连接到7号信令系统(SS7)电话网络，或由任何其他的适当的SMS网关提供者进行，且消息优选地从网关由呼叫路由器接收并转换为可通过公共互联网例如HTTP发送的格式(例如URI)，该发送基于SMS的接收地址例如短码、或直接向内拨叫(DID)、或其他的适当的唯一接收标识符。消息可以可选地是多媒体消息、传真发送、电子邮件、或任何其他的适当的消息发送媒体。PSTN设备的初始电话号码优选地使用呼叫者ID捕捉，但是任何其他的适当的ID都可被捕捉到，例如VOIP提供者ID、SMS设备号、电子邮件地址或短码。被拨叫的电话号码、EIN和/或计费标识符和/或呼叫的日期和时间还可优选地包括在会话信息中。认证ID可以另外地或可选地包括在会话信息中。
[0055]在一个变动形式中，步骤SI还起作用以通过HTTP或从在第三方服务器上运行的应用发送到呼叫路由器的其他请求来启动电话会话(例如电话呼叫)。在这个变动形式中，运行在服务器上的应用优选地为呼叫路由器指定初始URI以用于步骤S3中的电话会话，以及指定要拨叫的电话号码(或其他可寻址的目标)和源电话号码(呼叫者身份(id))。在这个变动形式中，呼叫路由器API优选地由应用服务器用来从呼叫路由器请求向外发出的呼叫。
[0056]陈述了将呼叫映射到统一资源标识符(URI)的步骤S3起作用，以使电话会话能够被转换为可由标准网络服务器和网络应用来处理的格式。该映射优选地使用呼叫路由器来执行。初始URI优选地在呼叫路由器由(可在第三方服务器上运行的)网络应用或呼叫路由器账户所有者预先指定。更加优选地，初始的URI通过呼叫目标的唯一标识符例如DID(直接向内拨叫)电话号码或VOIP SIP地址被分配给该呼叫。URI可以可选地由远程服务器或其他的适当设备或方法指定。在一个变动形式中，URI可用于封装来自被启动的电话会话的状态信息或状态信息的一部分，例如始发电话号码、被拨叫的电话号码、呼叫的日期和时间、呼叫者的地理位置(例如，国家、城市、州和/或邮编)、和/或唯一的呼叫ID。包括在URI中的信息可以URI模板的形式被包括在其中。例如URI缺省模板可以是:http://demo, twil1.com/myapp/ {被拨叫的电话号码} / {始发电话号码}或者http://demo,twil1.com/myapp/fo0.php ? dialed_number = {被拨口lI 的电话号石马}&originating_number = {始发电话号码}。
[0057]步骤S4起作用以数字地签名请求参数。如图16中所示，步骤S4优选地确定呼叫路由器账户所有者，且更加优选地，查找账户所有者的唯一 ID或密钥并签名一组请求参数。步骤S4优选地通过生成请求参数的加密散列(hash)来实现，优选地包括URI以及具有与呼叫路由器账户所有者相关联的唯一密钥的任何的请求体参数(例如，在HTTP POST的情况下)。加密散列优选地通过将请求参数附加到初始一组请求参数上的方式而生成。散列优选地附加到URI，但是如果散列特别长(即，具有大量的参数)，则散列可包括在对大小没有限制的HTTP报头中。在步骤S4的变动形式中，至少一个敏感参数可在散列被处理之前使用账户所有者的密钥来单个地加密。在另一个变动形式中，加密凭证授权系统例如Oauth (oauth.net)可以可选地用于对请求进行电子签名。
[0058]步骤S5起作用以向服务器发送请求。优选地，请求被发送到URI，且更加优选地，请求被发送到在步骤S3中所映射的URI。请求优选地包括由所述一组请求参数(作为数字签名起作用)计算得到的加密散列，但是如果参数被确定为包含敏感数据，则请求可以可选地包括单个加密的请求参数。服务器优选地是第三方服务器，且更加优选地，服务器运行网络应用。请求优选地通过网络被发送到服务器。在一个变动形式中，请求被发送到局域网上的本地服务器。在另一个变动形式中，请求被发送到在始发呼叫的设备上本地运行的服务器。在又另一个变动形式中，请求可被发送到多个服务器。请求优选地封装有来自被启动的电话会话的状态信息的至少一部分，例如始发电话号码、被拨叫的电话号码、呼叫的日期和时间、呼叫者的地理位置(例如，国家、城市和/或州、邮编)、和/或唯一的呼叫IDo更加优选地，请求封装了呼叫的所有状态信息，但是可以优选地不包括状态信息或包括部分状态信息。来自被启动的电话会话的状态信息优选地通过请求体中的HTTP POST、请求URI中的HTTP GET、HTTP报头参数来发送以模拟网络浏览器的数据流，或通过任何的组合方式或适当的可选方式发送。如果在呼叫路由器的操作过程中产生新的状态信息，则优选地向应用服务器作出请求以传递新的状态并请求新的电话指令。优选地，新的状态信息不被呼叫路由器保持或对其内部起作用，而是被传送到应用服务器以用于处理。可选地，部分状态信息优选地被存储在呼叫路由器上直到获得全面的更新状态，并随即被传送到应用服务器。例如，在当新的呼叫状态被获得并被传送到应用服务器之前，应用服务器可指定在键盘上应被按下的多个数字，而不只是一个。在一个变动形式中，来自被启动的电话会话的信息可以是包括在HTTP POST请求中的网络形式的提交。请求可包括来自电话会话的任何状态信息，例如始发电话号码、被拨叫的电话号码、呼叫的日期和时间、和/或唯一的呼叫ID、电话呼叫的当前状态(等待、正在进行、已完成等)、或电话行为的结果(包括双音多频(DTMF)数字处理)、或录音表示或录音的链接、或上一个命令的状态、或其他的呼叫状态。HTTP GET请求、HTTP POST请求以及HTTP GET请求的例子分别在图4A、4B和4C中示出。用于SMS消息发送的HTTP通信的进一步的例子在图4D、4E和4F中示出。向服务器的HTTP请求(或任何适当的请求通信)优选地遵循RESTful设计的原则。在本文档中RESTful被理解为描述了如本领域中所公知的表述性状态转移结构。RESTful的HTTP请求优选地是无状态的，因此从呼叫路由器发送到应用服务器的每个消息优选地包含应用服务器的操作和应用服务器的响应生成所需要的全部信息。呼叫路由器和/或应用服务器优选地不需要记住或存储先前的通信以获知所述状态。文档、媒体和应用状态优选地被浏览作为可寻址资源，与通过请求参数例如HTTP GET或HTTP POST参数或请求体内容而被提供到资源的数据进行组合。这样的请求数据可包括呼叫资源的更新后的表示，或作为呼叫路由器操作的结果生成的其他呼叫状态数据，例如键盘上被按下的数字或所生成的录音。每个请求中包括的状态信息可包括唯一的呼叫标识符、呼叫状态数据例如呼叫是正在进行中还是已完成、呼叫者的呼叫者ID、被呼叫的电话号码、关于呼叫者的地理数据、和/或任何适当的数据。但是，可使用变化水平的RESTful通信(无状态)，例如通过使用cookies、会话追踪、或任何适当的设备以模仿普通的网站访问者模型。优选地，与每个请求一起发送的数据完全可使应用服务器能够确定要执行的呼叫的下一个状态。RESTfulness优选地不排除使用外部数据源例如数据库，以查询另外的数据以记录呼叫元数据，或确定应用逻辑。
[0059]步骤S6起作用以验证请求参数的数字签名。如图13中所示，在服务接收到请求之后，请求参数优选地被检查和/或解析以用于散列。加密的散列优选地包括在HTTP请求的URI中，但是可以可选地包括在请求的HTTP报头中。如果请求不包括散列，且网络应用服务器以使能散列函数检查作为安全措施，则请求优选地被确定为假的，其可能包括一一例如一一恶意请求、错误路由请求、被破坏的请求和应用服务器不需要的任何其他请求。如果所述一组请求参数包括散列，则散列优选地从请求中提取，且客户网络应用的密钥(即，存储在呼叫路由器上与客户账户密钥相同的密钥)优选地用于生成所接收到的参数的服务器侧的加密散列。服务器侧加密散列优选地与包括在请求中的散列相比较，且如果散列不匹配，则请求优选地被确定为假。但是，如果服务器侧加密散列与请求散列相匹配，则请求优选地被确定为真实且准备好在应用服务器上进一步处理。在以上提到的步骤S4的变动形式中，其中敏感参数可使用密钥被加密，步骤S6优选地包括解密敏感参数。应用服务器和操作应用的第三方优选地负责完成这个验证步骤，但是验证可以可选地通过单方来完成，例如当单方操作应用服务器和呼叫路由器时来完成。如果请求认证对应用来说不重要，则应用服务器可以可选地设置为忽略包括在请求参数中的散列。
[0060]陈述了处理与电话会话相对应的请求的步骤S7起作用，以执行对包括在请求中的数据的至少一部分的处理。处理功能优选地在第三方服务器上执行。处理功能可包括记录包括在请求中的数据和/或与呼叫会话有关的元数据、路由到另一个UR1、执行包括在请求中的数据的至少一部分的数据库查询、语音识别处理、或任何其他的适当的处理功能。处理功能可再利用来自其他的商业应用的逻辑和数据，例如客户数据库和/或购物车应用，其可使用呼叫者id或呼叫者提供的信息来链接。状态信息优选地与来自呼叫路由器的每个请求通信，且优选地，应用服务器不需要应用状态。可选地，应用服务器可通过使用HTTPcookies、会话和/或数据库记录来存储与呼叫相关的每个请求之间的状态。在一些情况下，例如运行在服务器上的静态HTML页或被存 储的媒体文件例如存储在服务器上的mp3或wav文件的情况下，步骤S7可被简化，且通过URI映射到磁盘的文件可被简单地返回。
[0061]步骤S9陈述了来自服务器的响应。这个响应优选地是HTTP响应。响应优选地作为XML、音频二进制或原始文本被发送，但也可以可选地是任何种类的消息发送格式，包括HTML、界定文本、键/值文本或二进制编码格式。HTTP响应优选地包括执行电话操作的指示。响应可以可选地或另外地包括新的URI和新的URI模板以与步骤S3中的电话操作一起使用。另外的示例性XML响应在图5A和图5B中示出。
[0062]1B.处理电话指令
[0063]用呼叫路由器处理电话指令的步骤S120优选地起作用，以将服务器响应转换为电话操作或在电话会话期间可执行的操作。电话操作可包括例如在服务器指定的URI (例如位于http://demo, twil1.com/myapp/1234.mp3的静杰mp3文件)播方文预先录制的声音文件、使用文本转语音技术为呼叫者读文本、呼叫另一个号码(例如通过PSTN、SIP/VOIP或其他的IP技术系统创建新的语音连接)、通过DTMF输入收集数字、记录语音响应音频、TTY或其他的数据、发送SMS消息、或者这些或其他的适当的操作的任何适当的组合或顺序。服务器响应的这个转换优选地在呼叫路由器上执行。优选地，步骤S120包括处理于服务器响应相关联的响应mime-类型。例如，如果响应mime-类型是XML，其被认为是一组呼叫路由器指令。如果响应mime-类型是MP3，其被认为是为呼叫者播放的声音文件。如果响应类型是纯文本，其被认为是通过文本转语音技术读给呼叫者的文本。
[0064]服务器响应的内容例如XML文档优选地通过顺序地(例如，逐行地)处理文档的方式被转换为电话操作。电话指令优选地以标记语言例如图5A和图5B中所示出的XML的形式被包含在文档中。处理电话指令的文档的这个连续的方式在通信是无状态且所有必要的信息都包含在URI中时有效。这个无状态通信优选地允许电话指令(动词或命令)被用作服务器应用用于执行电话服务的编程接口。电话动词或文档的(基于通信状态的)算法转换优选地为不必要的。优选地，按照服务器响应的内容中含有的电话指令的顺序来执行电话操作。例如，XML文档可包括必要的动词以实现为呼叫者读文本、监控由呼叫者按下的键、以及使用被按下的键作为新的URI的数据的部分来将呼叫者重定向到新的URI的电话操作。优选地，电话操作(例如被按下的数字)产生新的状态信息，这可导致方法的一些步骤的重复，优选地从步骤S3开始重复。下一个URI优选地由服务器提供作为处理指令的部分。在另一个变动形式中，如果服务器未能指定下一个URI则重复使用上一个URI。在又另一个变动形式中，如果服务器未能指定下一个URI则不发生重复，且过程向下进行下一个呼叫文本路由器指令。可通过呼叫路由器指令的性质确定行为；例如，没有产生新的状态信息的指令可能不需要有下一个URI，因为他们不触发与远程服务器的通信。更加优选地，电话操作导致步骤S3利用从步骤Sll得到的新的URI进行重复，但是可以可选地启动方法的一个或多个步骤(步骤S5、S7、S9或Sll)的重复。步骤S3优选地使用由执行电话操作产生的所有新的电话会话状态信息例如被按下的数字、录制的音频文件或被请求的任何电话操作的成功或失败信息来重复。重复还包括在会话期间保持相关的所有状态信息，例如呼叫者、被呼叫者、唯一呼叫ID和呼叫状态。状态信息还可以URI模板的形式表示。例如，如果服务器响应指定呼叫路由器收集DTMF数据，并指定下一个URL是URI模板http: //demo,twil1.com/fo0.php ? digits = {Digits}，且呼叫者按下 1234，得到的 URI 是 http://dem0.twil1.com/fo0.php? digits = 1234。类似地，如果服务器响应指定URI模板:http://demo, twil1.com/myapp/ {Digits}.mp3，所得到的 HTTP 请求可能是位于:http://demo, twil1.com/myapp/1234.mp3的静态mp3文件。因此，呼叫可由发出电话指令的服务器和处理响应的第二个服务器控制，如图13和图14中所示。这样的呼叫控制转接构成了状态信息以URI和附带的请求数据例如GET、POST和/或请求体的形式在服务器之间的转换。可选地，所有的状态通信遵循由呼叫路由器建立的句法，以促进多个服务器之间的集成。例如，在键盘上按下的数字优选地以相同的形式被传送到应用服务器，因此使对在多个应用服务器之间关于状态如何转换的协作的需要最小化。可选地，呼叫路由器指令可规定传递新的状态信息例如变量的名字和类型的方法，以发送代表性的新的状态。
[0065]1C.创建可由呼叫路由器API访问的资源
[0066]创建可通过应用程序接口(API)访问的呼叫路由器资源的步骤S130优选地起作用，以暴露呼叫路由器的信息和/或功能。来自外部多方的交互优选地通过API (呼叫路由器API)执行。呼叫路由器API可另外地与电话指令的使用协作，以作为对于由呼叫路由器的操作生成的或需要的数据的存储和取回格式而起作用。呼叫路由器API优选地是应用程序接口(API)，例如本领域中所知的REST API (表述性状态转移)，但是呼叫路由器API可以可选地是SOAP(简单对象访问协议)API或任何适当的编程式通信接口。呼叫路由器API优选地可由应用异步地用于执行呼叫(以便在以后查询呼叫记录或取回记录)。可选地，呼叫路由器API可在呼叫的过程中同步使用(例如改变呼叫状态、挂断呼叫、启动呼叫记录等)。呼叫路由器API优选地将状态信息存储在资源的持久URI中。持久URI优选地包含所有的必要的状态信息，且这优选地使得数据稳定、可查询且可恢复。呼叫路由器API优选地用于修改资源以改变呼叫路由器的状态并用于与呼叫路由器的媒体交互。应用服务器可使用呼叫路由器API，以优选地查询呼叫记录的元数据、呼叫者身份、呼叫媒体(例如记录、文本副本等)、账户信息、呼叫路由器中的转移或与正在进行的通信的交互、和/或操作呼叫路由器生成的或需要的任何适当的数据。呼叫路由器API优选地涉及应用服务器和呼叫路由器之间的通信，但是可以可选地是从任何适当的设备到呼叫路由器的通信。呼叫路由器API优选地存在于与呼叫路由器相同的硬件上，但也可以可选地存在于远程硬件或任何适当的硬件环境中。通信优选地为HTTP，但是可选地可使用HTTPS或任何适当的通信协议。另外，呼叫路由器API还可与任何HTTP客户端兼容。优选的实施方式的电话系统优选地实现包括呼叫路由器API请求格式、呼叫路由器API响应格式以及代表由呼叫路由器生成或使用的数据的类型的多个API资源的呼叫路由器API。
[0067]优选的实施方式的呼叫路由器API请求作为从应用服务器发送到呼叫路由器的API资源的通信消息起作用。呼叫路由器API请求优选地从应用服务器发送到呼叫路由器，但是也可从任何适当的设备发送到呼叫路由器。呼叫路由器API请求优选地类似于RESTAPI请求，但是呼叫路由器API请求可以可选地遵循任何适当地程序设计，例如SOAP。呼叫路由器API请求优选地使用HTTP与资源交互，但是也可使用HTTP或任何适当的通信协议。优选地，GET的HTTP或HTTPS方法用于取回资源或资源信息，且PUT或POST的HTTP或HTTPS方法用于创建或更新资源。在一些情况下，PUT或POST可用于通过修改资源的状态来影响呼叫路由器的功能。可选地，方法参数可包括在资源的URI中，以识别对于资源的被请求的操作，或者也可使用任何适当的命令或方法来与API资源进行交互。优选地，通过在URI中包括消息认证信息例如使用共用密钥的请求内容的加密散列，或通过任何适当的方法，呼叫路由器API请求包括认证例如基本的HTTP或HTTPS认证。
[0068]优选的实施方式的呼叫路由器API响应作为响应于在API资源上执行的方法而发送的通信信息来起作用。呼叫路由器API响应优选地从呼叫路由器发送到应用服务器或任何适当的设备。呼叫路由器API响应优选地响应于呼叫路由器API请求而发送，且响应优选地被发送到始发设备。呼叫路由器API响应优选地与REST API响应相似，该响应代表所请求的资源。呼叫路由器API响应可以可选地遵循任何适当的程序设计例如SOAP。呼叫路由器API响应优选地作为格式化XML而被返回，该格式化XML带有与HTTP状态代码对应的信息、消息、错误代码和/或与资源相关的任何适当的信息。呼叫路由器API响应可以可选地被表示为逗号分隔值列表(CSV)、HTML、JSON或任何适当的形式。在一个变动形式中，响应格式由所请求的URI的一部分例如文件扩展来确定。在一个变动形式中，API资源可以是二进制数据资源，且呼叫路由器API响应优选地被格式化为本机二进制格式(例如，wav或mp3音频文件)、XML元数据描述和/或任何适当的格式。
[0069]优选的实施方式的API资源作为呼叫路由器元数据、内部呼叫路由器状态、或由呼叫路由器使用的给定资源的状态的可寻址表示而起作用。优选地，API资源由持久URI寻址。优选地，API资源响应于POST、PUT、GET或DELETE的至少一个HTTP操作。API资源可以可选地响应于多个HTTP操作。API资源可以可选地响应于优选地包括在呼叫路由器API请求中的任何适当的方法。与RESTful惯例一致，资源的GET请求可返回资源的当前状态，而PUT可更新状态，PUT或POST可用于创建新的资源，DELETE可用于破坏资源。呼叫路由器API除了修改数据外还可以可选地用于影响正在进行的呼叫的功能。优选的实施方式的API资源包括账户资源、呼叫者ID资源、呼入的地址资源、呼叫资源、媒体资源和/或呼叫路由器的任何适当的资源。API资源可以可选地为所列出的资源或其他的适当的资源的任何适当的组合。API资源优选地是预配置(或者“静态”)资源，例如账户信息，或由呼叫路由器使用的活动状态的资源例如电话呼叫。通过API修改资源状态另外还可以实时地影响呼叫路由器的操作，影响呼叫路由器在将来的呼叫状态或能力，和/或具有任何适当的影响。
[0070 ]优选的实施方式的账户资源起作用，以允许应用取回和/或修改账户信息。账户优选地由电话服务器提供者例如呼叫路由器的操作者创建。例如账户名字、使用信息、联系信息、初始UR1、设置参数的信息或任何适当的账户信息可由应用使用账户资源来取回或编辑。
[0071]优选的实施方式的呼叫者ID资源起作用，以允许应用取回、修改、注册新的呼叫者ID(电话号码)、和/或删除呼叫者身份信息。优选地，呼叫者身份信息是针对于与由应用和/或用户(即，显示为发出呼叫的应用)进行的向外的呼叫相关的电话号码的。对于向外的呼叫的号码优选地在被用作呼叫者ID之前被分配和验证。作为可选方式，为了防止应用中的呼叫者ID电话号码被冒用，可在增加新的呼叫者ID资源之前由API使用验证步骤。增加呼叫者ID的请求可通过请求被始发到API，其中随机校验码被产生并在API响应中返回。校验码优选地被提供到终端用户。向所给的电话号码(呼叫者ID)进行电话呼叫，以请求通过键盘数字或口头输入检验码。在请求的时候，检验码的输入验证电话号码的所属或者与电话号码相关联的设备。呼叫者ID资源的使用还可通过显示检验码的方式在用户界面例如网络浏览器上呈现。用户接口可由呼叫路由器的操作者提供，或可由任何适当的应用使用API来提供。可将任何适当的方法用于呼叫者ID的验证。在呼叫涉及到多方的另一个可选方式中，可在那个呼叫会话期间为另外的向外呼叫分配一个现有方成员的呼叫者ID。
[0072]优选的实施方式的呼入的地址资源起作用，以允许应用获得、修改或提供新的向内DID电话号码、SMS短码、SIP地址等以用于应用。PUT或POST可用于设置与向内地址相关联的初始URI。DELETE可用于释放资源。呼入地址资源可用于电话号码或其他的可寻址向内标识符的实时提供。
[0073]优选的实施方式的呼叫资源起作用，以允许应用获得或修改呼叫路由器中的电话会话的状态。电话会话或呼叫可以是正在进行中、已完成、失败、未启动、和/或处于任何适当的呼叫状态。呼叫资源优选地可改变正在进行的呼叫的状态或连接。状态改变优选地包括:挂断或终止现有的电话会话、将一个或多个现有的电话会话从会话的一个环境组转移到另一个、合并或拆分现有组电话会话、将一个或多个电话会话从一个通信媒体转移到另一个(例如从一个URI转移到第二个URI)、将事件或通知引入到现有的会话或会话组、记录或停止记录来自呼叫的一方或多方的音频、和/或任何适当的呼叫操作。呼叫信息或呼叫日志数据优选地可通过发送GET到呼叫资源或可选地通过发送任何适当的方法来取回。向外的呼叫还可通过使用POST或优选地表明新的呼叫资源被创建的任何适当的方法来启动。当使用呼叫资源来启动呼叫时，可按需要提供信息以进行电话呼叫，该信息为例如要呈现的呼叫者ID、要呼叫的电话号码、和/或用于处理呼叫的URI，但是可选地可提供任何适当的信息。可选地，呼叫指令XML文档可代替URI被提供到API，其用于呼叫指令。例如当呼叫被应答时、当机器应答电话时、忙信号、无应答、呼叫失败和/或在任何适当的呼叫状态时，呼叫路由器API也可另外用呼叫的状态作出响应。可选地，该响应可表明新的呼叫请求已被接受但尚未启动。在图6中示出的例子中，呼叫者信息和呼叫者ID包括在向呼叫资源的POST请求中。这个步骤可能启动向呼叫信息中指定的电话号码的向外呼叫。呼叫路由器API响应包括与呼叫有关的有效状态信息，例如呼叫是否已经开始、呼叫开始时间、结束时间、价格、呼叫者信息，且可选地，呼叫路由器API响应可包括任何适当的信息。另外，由API在任何时间点返回的与呼叫有关的信息可取决于呼叫的状态。例如，如果呼叫尚未开始，则呼叫开始时间可不被给出，如果呼叫尚未结束，则呼叫结束时间、持续时间或价格可不被给出。
[0074]另外地或可选地，优选的实施方式的呼叫资源可用于通过单个呼叫资源接收POST、PUT和/或任何适当的方法来将呼叫转移到新的URI。在这种可选方式中，呼叫可选地被转移到对于新的呼叫指令的新的URI。优选地，API可用于引发呼叫状态的异步的改变，这与呼叫路由器和应用服务器之间的用于同步URI请求和响应的同步通信不同。在这种可选方式中，呼叫资源起作用以允许呼叫被异步地指向到多个URI。呼叫资源的各种应用的例子包括启动新的电话会话、终止现有的电话会话、呼叫等待、呼叫保持、呼叫排队、呼叫驻留、会议内的专有呼叫会话、多个呼叫会话的进行、和/或任何适当的应用。异步事件影响呼叫状态的任何情况例如呼叫代理变为有效，或在将呼叫者置于保持状态后有人回复电话。在请求所提供的URI之前，可允许完成或可立即终止当前执行的呼叫路由器指令。由呼叫路由器执行的上一个呼叫指令得到的新的呼叫状态，例如键盘上被按下的数字或被记录的来自呼叫者的音频，可以通过POST或GET参数的形式被提供给新的URI，或可以可选地被呼叫路由器丢弃并不被提供。如图15中所示出，呼叫等待可通过由应用发送呼叫路由API请求到为呼叫POST新的URI的呼叫资源的方式来实现。然后呼叫者被指向到指令的新的URI。第二个呼叫路由器API请求被发送到为呼叫POST始发URI的呼叫资源，且因此使呼叫者回到第一个呼叫会话。呼叫资源可以可选地用于任何适当的应用中。
[0075]作为呼叫资源的可选的实施方式，呼叫资源可实现多个独立呼叫作为不同的子资源。例如，以“/Calls”结尾的URI可以是由账户执行的一系列多个呼叫，以“/Calls/12345”结尾的URI可代表由密钥“12345”唯一识别的一个指定的呼叫。呼叫资源优选地允许取回很多呼叫记录和/或创建新的呼叫，而单个呼叫资源代表单个呼叫。呼叫资源优选地接受创建新呼叫资源的请求，如在RESTful结构中所常见的，其在呼叫路由器API中，优选地用来启动一个或多个新呼叫。呼叫资源可用于使用GET方法列出当前的和先前的呼叫，以及使用POST方法启动新的向外呼叫。使用RESTful原理例如POST或PUT来改变独立呼叫资源的状态可以可选地例如通过挂断、将控制转移到新的UR1、将呼叫与另一个呼叫接合或以任何适当的电话操作的方式来改变正在进行的呼叫的状态、影响呼叫的实时操作。
[0076]优选的实施方式的媒体资源起作用，以允许应用取回和/或访问在呼叫过程中所存储、取出、创建和/或使用的媒体的信息。在一个变动形式中，媒体资源优选地是记录资源，以访问信息以及在呼叫期间通过记录呼叫指令或异步地通过呼叫路由器API而作出的记录。在另一个变动形式中，媒体资源可以可选地包括呼叫副本、文本消息、按键日志、传真、二进制码资源和/或任何适当的媒体。媒体资源可以可选地包括二进制码文件(例如wav、mp3音频文件或PDF文档文件)的URI。在一个变动形式中，媒体资源还可与电话指令(或标记语言)合并，以使得电话指令可指示呼叫路由器执行创建媒体资源的操作。呼叫路由器优选地以所创建的媒体资源的URI发送响应到应用服务器。例如，当呼叫路由器被指示记录消息时，呼叫路由器优选地以API中所记录的消息的唯一 URI发送响应到应用服务器。媒体URI优选地响应GET请求以返回多种格式的媒体，例如二进制或XML元数据表示。媒体资源可接受删除媒体资源的请求。在一个变动形式中，媒体资源优选地需要访问资源的认证。在另一个变动形式中，媒体资源可不需要使URI能够嵌入多个应用的认证，也就不暴露认证凭证。在又一个变动形式中，认证优选地通过加密散列来执行，以使得凭证不被暴露给消费媒体资源的客户端应用。在另一个变动形式中，媒体资源允许使用转录技术启动音频资源向文本的转录。用于转录的音频资源优选地在电话会话期间产生(例如通过记录指令)并以呼叫路由器API为主机。媒体资源优选地允许取回或删除由所记录的媒体生成的音频转录。媒体资源还可允许集中控制媒体文件，且资源URI优选地在呼叫路由器和应用服务器之间而不是在大媒体文件自身之间交换。媒体资源可以可选地用于任何适当的媒体。
[0077]另外地或可选地，优选的实施方式的接合资源可用于将一个或多个呼叫接合到共享会话中，其允许多方通过单个呼叫资源接收P0ST、PUT的方式和/或通过任何适当的方法来通信(即，进行会议)。在这个可选方式中，优选地，一个或多个呼叫接合到一起以使得它们在一个会议中。接合资源可以可选地是子资源或呼叫资源的部分。
[0078]另外地或可选地，优选的实施方式的拆分资源可用于通过单个呼叫资源接收POST,PUT的方式和/或通过任何适当的方法将共享的会话(例如，会议)拆分为独立的呼叫会话。在这个可选方式中，涉及两个或多个呼叫的一个或多个共享会话优选地被拆分，以使得一个或多个呼叫被拆分成多个分离的呼叫或拆分成一个或多个分离的会议。拆分资源可以可选地是子资源或呼叫资源的部分。
[0079]2.用于处理电话会话的系统
[0080]如图2A、2B、3A和3B中所示，用于处理电话会话的优选的实施方式的系统20和30包括呼叫路由器22、应用服务器的URI 23、电话指令27，以及呼叫路由器资源29。如图2A和2B中所示，第一设置20由电话设备(例如电话呼叫、传真或SMS消息)启动。如图3A和3B中所示，第二设置30由应用开发者侧(即，呼出的服务器26)启动。优选的实施方式的电话系统优选地还实现呼叫路由器API 28，其包括呼叫路由器API请求格式、呼叫路由器API响应格式和实质上与以上描述的那些资源类似的多个资源。
[0081]呼叫路由器22起作用以启动呼叫或从电话设备接收呼叫并连接到网络应用服务器。呼叫路由器22优选地通过PSTN网络连接到PSTN设备，以使得其可从PSTN连接的设备21以及非PSTN设备接收呼叫和进行呼叫，PSTN连接的设备例如固定电话、蜂窝电话、卫星电话、或任何其他的适当的PSTN连接的设备，非PSTN设备例如网络语音(VOIP)电话、SIP设备、Skype、Gtalk、或其他的互联网可寻址语音设备。呼叫路由器22可以可选地或另外地作为用于SMS消息的消息路由器起作用或包括用于SMS消息的消息路由器。呼叫路由器22可以优选地连接到SMS网络，以使得其可从SMS网络设备21、蜂窝电话、计算机、智能电话或任何适当的SMS网络设备接收消息和发送消息。呼叫路由器22还可发送或接收文本消息、多媒体消息、电子邮件、传真和其他适当的可PSTN兼容的通信消息。呼叫路由器2 2优选地使用应用层协议与应用服务器26通信，更加优选地使用HTTP协议或安全HTTPS协议与应用服务器26通信。应用服务器26和呼叫路由器22之间的通信优选地是无状态的通信，且任何状态信息(例如呼叫状态)或数据优选地位于URI或请求参数中，例如HTTP报头、GETURI参数、POST请求体参数或HTTP cookies中。有效的状态信息优选地由呼叫路由器请求发送到应用服务器以用于无状态处理，且应用服务器优选地不存储状态。可选地，应用服务器优选地存储网络开发中常见的本地状态信息，例如数据库或会话。呼叫路由器22优选地存储状态信息在呼叫路由器资源29中。呼叫路由器资源29优选地由应用服务器26和其他设备通过呼叫路由器API 28访问。呼叫路由器资源29优选地与以上描述的那些资源相似。呼叫路由器22优选地将每个呼入电话号码与起始URI 23相关联，更加优选地，URI 23由应用服务器26提供，又更加优选地，在呼叫路由器22接收到呼叫之前，URI 23由应用开发者通过将初始URI与呼入呼叫地址(例如DID、SIP地址等)相关联的方式提供，或在启动向外呼叫时由应用来提供。呼叫路由器22优选地发送呼叫数据例如(通过呼叫者ID获取的)呼叫者号码、呼叫者地理数据(国家、城市和/或州、邮编)、被拨叫号码、呼叫的时间、或任何其他的适当的信息或参数。呼叫数据优选地用存储在呼叫路由器22上的密钥25进行数字签名。信息的加密散列优选地连同该信息一起被包括作为数字签名。呼叫路由器22还可(在加密散列被计算之前或者之后)使用密钥加密敏感信息，以允许敏感信息通过网络被发送。呼叫数据优选地作为HTTP POST请求被发送到应用服务器26。呼叫数据还可在URL(GET)变量中被发送，或被封装在HTTP报头中。在图4A和4D中示出包含报头中的信息的示例性HTTP请求。如图4B中示出，来自PSTN设备的进一步的输入(例如语音记录或按DTMF按钮)可作为HTTP请求(GET或POST)被接连地提交到应用服务器26。如图4C中所示出，来自电话键盘的输入可包括在HTTP GET请求中。如图4E中示出，由呼叫路由器接收的SMS消息内容可作为HTTP请求被发送到应用服务器26。如图4F中示出，来自下一条消息的输入包括在HTTP GET请求中。请求数据可以可选地在URL (查询字符串)、消息体(POST)和消息报头或以上的任意组合中同时发送。
[0082]应用服务器26起作用，以为从呼叫路由器22接收的请求提供数据处理逻辑。应用服务器26优选地通过网络24、更加优选地通过互联网连接到呼叫路由器22。应用服务器26优选地是在系统外部操作的第三方服务器，但是该系统可以可选地包括应用服务器26。URI 23优选地与应用服务器26或应用服务器26上的应用相关联。应用服务器26优选地使用应用层协议、更加优选地使用HTTP协议或更加安全的HTTP协议与呼叫路由器22通信。应用服务器26优选地从呼叫路由器22接收HTTP请求或发送HTTP请求到呼叫路由器22。应用服务器26优选地在编程语言、主控提供者、操作系统和数据库的标准栈上运行，以处理HTTP请求，如同呼叫者是网络浏览器中的网站访问者一样。应用服务器26可优选地使用密钥来验证在请求中接收到的呼叫数据的数字签名，以从所接收到的信息和所接收到的散列来计算加密散列。如果所计算的散列和所接收的散列不匹配，或没有接收到请求中的散列，那么应用服务器26优选地确定该请求为假，且优选地，该请求被丢弃。如果所计算的散列和所接收的散列匹配，则应用服务器26优选地确定请求是真实的，并进一步进行对请求的处理。如果安全不重要，则应用服务器可以可选地选择忽略散列。应用服务器优选地使用由呼叫路由器请求传送的呼叫状态数据来确定下一个呼叫路由器指令，而不需要存储在应用服务器上的呼叫状态。应用服务器可以可选地使用由呼叫路由器发送的呼叫状态数据，例如呼叫者的呼叫者ID或呼叫的唯一 ID，以参考另外的或外部的状态数据，例如数据库中的行或存储在应用服务器上的会话数据。应用服务器26优选地通过产生对于呼叫路由器22的电话指令27，来响应从呼叫路由器22接收的HTTP请求。应用服务器优选地以XML回复呼叫路由器，但是，也可使用任何适当的机器可读的消息格式，包括HTML、键/值对文本、界定文本或二进制编码。XML优选地包括对于呼叫路由器22的电话指令27，例如连接到另一个号码、播放已录制的问候、读文本、和/或请求呼叫者的DTMF数字输入。电话指令27可以可选地与SMS消息发送、多媒体消息服务(MMS)消息发送、电子邮件或任何适当的消息发送任务相关。电话指令27还可用于发送向外的SMS消息、排列来自具体电话号码的电话呼叫、安排回叫、建立会议呼叫(连接多个号码)、发送电子邮件、与日历或日程安排系统交互、购物、或服务、或任何其他适当的指令。XML指令优选地是按顺序每次执行一个(即顺序地执行)的一组命令。示例性的XML响应在图5A和5B中示出。在单个的电话会话(例如，由PSTN设备或SMS设备启动的电话会话)中，来自应用服务器的响应可启动向外的电话会叫和/或SMS消息。也就是说，单个的XML响应优选地提供与SMS网络和语音电话网络(PSTN、SIP、VoIP等)顺序地或同时地进行交互的能力。另外，被发送到呼叫路由器22的音频或视频文件可由自动语音转文本引擎、人工或其他技术转换为文本，并以文本形式作为SMS消息或MMS的附件被发送回。在一个变动形式中，运行在服务器上的应用可以是部署在没有可用的开发或编写脚本的环境的静态网络服务器上的简单的静态XML页和静态的声音文件。这个变动形式优选地使用URI模板(IETF目前推出的HTML5)，其基本包括带有可变数据的占位符的URL，如:http://www.twil1.com/aud1/{Digit}.mp3，其中呼叫路由器22将用按下的数字代替URI模板中{Digit}占位符，在得到的URI处GET文件，并播放静态声音文件作为响应。这允许整个应用在所见即所得(WYSIWYG)html编辑器中被离线编写。例如，如果服务器响应指定URI模板:http://dem0.twil1.com/myapp/{Digits}.mp3，呼叫者按数字 1234，呼叫路由器 22 将 GET 位于 http://demo, twil1.com/myapp/1234.mp3的静态mp3并将其播放给呼叫者。URI目标中用作替代的变量优选地与为来自呼叫路由器的HTTP GET、POST和/或报头请求中的状态提交而定义的变量的名字相对应。由先前的例子可知，{Digits}可与优选地作为“聚集”电话指令(DTMF数字的集合)的结果而产生的名称为“Digits”的参数相关联。在对于第二个设置的优选实施方式中，呼叫由应用服务器26 (通过呼叫路由器22)启动，且第二个设置30实质上与第一个设置20相似，以使得呼叫路由优选地被同样地处理到进入的呼叫，也就是当呼叫状态改变时通过从呼叫路由器22到服务器26的URI请求进行处理。应用服务器还优选地能够作出向呼叫路由器API的呼叫，如以上所述。
[0083]3.示例件应用
[0084]呼叫路由器应用优选地是网络应用，以实现具有用于管理的全API的最普通的电话系统特征。每个呼叫路由器应用对象具有唯一的URI。呼叫可通过指定其URI作为呼叫目标的方式被转移到那个对象实例。呼叫路由器应用优选地包括:AutoAttendant应用(在图7 中)、Follow Me 应用(在图 8 中)、Conference 应用(在图 9)中、Autoconference 应用(在图 9-11 中)、Device 应用、Person 应用、VoicemailBox 应用、Group 应用以及 Queuing应用(在图12中)。
[0085]如图7中例举的AutoAttendant应用播放已录制的问候，并等待呼叫者按键盘上的一个或多个数字。基于输入，AutoAttendant优选地将呼叫指向另一个AutoAttendant、人们的电话中的一个或多个、语音邮箱或任何其他的有效的呼叫目标。
[0086]如图8中例举的Follow Me应用使得能够用多个设备例如工作号码、蜂窝电话号码、固定电话和/或网络语音电话设备联系到人。Follow Me应用优选地按顺序地或同时呼叫这些设备，以试图联系到人。
[0087]Stay With Me应用使得人们能够在多个电话设备例如蜂窝电话和家庭电话之间转移正在进行的呼叫。例如，用户可能希望将呼叫从比较昂贵的蜂窝电话转移到不那么昂贵的固定电话上，或者，可能希望在蜂窝电话电池即将用尽时将呼叫转移到固定电话上。
[0088]图9中例举的Conference应用优选地允许三个或多个呼叫者同时参加呼叫，同时提供控制谁可在呼叫期间加入并说话的机制。Conference应用可以可选地或另外地合并SMS消息发送控制。当接收到包括多个电话号码的SMS消息时，Conference应用可使用单个SMS启动向一方或多方的会议呼叫。
[0089]AutoConference应用优选地允许会议管理者通过执行一个操作来启动与两方或多方的会议呼叫，该操作例如选择网站上的按钮、选择电话设备上的按钮、拨叫电话号码、或在其启动之前排定呼叫。使用本发明的优选的实施方式实现的AutoConference应用的例子在图9 (从PSTN设备侧观看)、图10 (从应用服务器侧观看)以及图11 (由使用呼叫路由器API的应用服务器启动)中示出。
[0090]Device应用表示在电话系统中使用的电话，且可以是硬电话(硬件)或软电话(软件)、VOIP电话或传统的PSTN电话。Device应用处理设置细节和设备状态(免打扰、忙碌等)。
[0091]Person应用表不电话系统的真人用户。Person可具有一个或多个分机、设备和/或语音邮箱，且可具有拨打他们的电话或语音邮箱的优选的顺序。人们可有用来登录和更新这些设置的用户名和口令。
[0092]VoicemailBox应用优选地播放问候，并允许呼叫者记录消息。当完成之后，已录制的消息可被存储以用于以后收听、可作为语音连接或附件或这两者被电子邮寄。可通过AP1、通过RSS源和/或任何其他的适当的方法或设备拨叫，取回对于语音 邮箱的一系列当前消息。在一个变动形式中，音频记录可被自动转录，将语音转换为文本。文本优选地连同音频链接、附件被包括在电子邮件或文本消息中，并/或可在以后由任何适当的API工具取回。
[0093]Group应用优选地表示其他的呼叫路由器应用对象的逻辑组，包括其他的组。组优选地限定被指向到组的呼叫的行为，包括排队、搜索第一个可用的被呼叫方，以及同时拨打多个被呼叫方。
[0094]当接收到电话呼叫或SMS消息时，Queuing应用优选地输入消息发送者到电话呼叫队列，且消息发送者通过PSTN、SIP/VoIP网络或其他的电话网络回呼，如图12中所例举的。当人/操作者/服务(客户服务应用)中任一项在预先安排的时间可用时，可进行对消息的始发号码或另一个预先制定的号码的呼叫，例如叫醒电话、周年纪念提醒、生日提醒。
[0095]呼叫路由器应用可另外地或可选地包括:
[0096]Busy Signal Buster服务，其在接收到SMS消息或电话呼叫时，发送要被呼叫的当前正忙碌的号码，并在该号码不再忙碌时以消息的始发号码或另一个预先制定的号码向SMS消息发送者回呼；
[0097]SMS Reader/TTY应用，其在接收到SMS时，使用文本转语音引擎为呼叫者或音频会议的成员将文本转换为音频(例如，告诉他们你们将在几分钟后加入呼叫)，或由听力受损者使用以取代TTY服务；
[0098]Translat1n应用，其在接收到包含某种语言的短语时，将SMS消息的语言(人工地或者由程序自动地)转换为另一种语言并通过SMS或电子邮件发送响应消息；以及
[0099]Programming应用，其在接收到包含编程代码的SMS消息时，可编译代码并执行代码、更新网站、更新编程项目、从数据库返回数据、作为MMS消息返回生成的计算机图形对象、或任何其他的适当的程序编译或计算。
[0100]呼叫路由器应用可另外地或可选地包括Status/Notificat1n应用，该应用允许用户通过经由PSTN、SIP/VoIP网络或其他电话网络发送SMS消息和接收回呼，获得或发送对象、任务或过程的状态。该服务可由发送带有特定服务器的名称的SMS消息的操作者使用，且然后获得在其移动电话上的回呼，并听到那个服务器的状态被出声地读出。该服务还可用于通知，即，用于呼叫其他的被叫方。例如，存储管理器可能需要让雇员知道存储器在第二天的什么时间开放。管理器可发送SMS消息，这将在随后呼叫每个雇员并通过电话告诉他或她存储器在第二天的什么时间开放以及/或他们需要在什么时间上班。
[0101]但是，呼叫路由器应用可包括这些或其他的适当的预建立的电话函数和特征的任何集合和/或排列。
[0102]优选的方法的应用可包括简单的PBX功能，例如自助语音菜单、雇员扩充以及语音邮件特征。应用还可包括其他的、非常规的应用例如Interactive Hold应用、ConferenceCalling 应用、Independent Music Hold Channel、Voting/Fundraising 应用、Sales 应用、Blog by phone 服务以及 Call Annotat1n 应用。
[0103]Interactive Hold应用优选地包括交互活动，例如在等候接听时进行答问比赛(具有或不具有与其他呼叫者竞争的能力)、收听新闻头条或听者的选择的语音播客，以及使用电话键盘作为合成器实时来创建音乐。作为例子，Conference Calling应用可包括从电话本中选择特定的(或随机的)用户并向组证实会议呼叫，具有保留所述组以用于将来的呼叫的能力。Independent Music Hold Channel优选地在呼叫者等候接听时允许独立的艺术家上载、分类他们的作品并准许播放他们的作品。Voting/Fundraising应用优选地将有意愿的呼叫者(呼叫以鼓励投票或为事业筹集资金的呼叫者)分别连接到潜在的投票者和/或捐赠者，优选地包括呼叫者用于显示与投票者/捐赠者有关的信息的接口，并记录关于投票者对呼叫的反应。Sales应用优选地允许销售组织快速地将向内的和向外的呼叫与客户关系管理(CRM)应用集成，或从购物车应用读订单详细信息。最后，Call Annotat1n应用允许呼叫参与者附加元数据，例如电话交谈中使用的参考URI，以指定呼叫和呼叫中的时间戳。有适当的用户代理的呼叫的参与者可在呼叫期间查看注释，听呼叫音频的后来的重播的人还可在回放期间以相同的时间戳接收这样的注释。Call Annotat1n可用于例如促进会议呼叫记录的进行、雇员培训、销售团队合作和/或顾客支持合作。
[0104]应用可以可选地包括保持或驻留功能，其中呼叫者处于等待状态直到外部的事件恢复呼叫，例如另一方变为有效。这个应用的一个变动形式是呼叫队列，其中呼叫者等待有效的服务人员应答呼叫。优选的方法的应用可以可选地包括其他的传统的或非传统的PBX功能。
[0105]本领域中的技术人员将从先前的详细描述以及从附图和权利要求中认识到，可对本发明的优选的实施方式作出修改和改变而不偏离以下的权利要求所限定的本发明的范围。可能地并确实有希望地，基于本技术平台(本发明的优选的方法和/或系统)设计和建立以其他方式的可能不使用传统的电话平台的另外的应用。
【主权项】
1.一种用于处理电话通信的方法，包括: 将初始URI与电话端点相关联； 启动用于到所述电话端点的电话通信的电话语音会话； 将所述初始URI映射到所述电话语音会话； 将应用层协议请求发送到由所述URI指定的应用资源，并且将所述电话语音会话的状态信息嵌入到所述请求中； 接收发送到所述应用资源的所述应用层协议请求的响应，其中所述响应包括电话指令的文档；以及 根据对所述响应的所述电话指令的至少一个子集的顺序处理，在所述电话语音会话期间执行电话操作。2.如权利要求1所述的方法，其中所述电话通信是呼叫。3.如权利要求2所述的方法，其中，执行电话操作包括通过公用交换电话网络PSTN进行通信。4.如权利要求1所述的方法，其中，执行电话操作包括在所述电话语音会话期间进行以下电话操作:播放音频、播放文本到语音的视频，捕获输入、呼叫电话端点或录制音频。5.如权利要求1所述的方法，其中执行电话操作包括发送电话消息，所述电话消息被发送到电话端点。6.如权利要求5所述的方法，其中，发送所述电话消息包括通过七号信令系统SS7的网络进行通?目。7.如权利要求5所述的方法，其中所述电话消息是短消息服务SMS消息和多媒体消息服务MMS消息中的至少一个。8.如权利要求1所述的方法，其中所述电话端点是电话号码和会话启动协议SIP地址中的至少一个。9.如权利要求1所述的方法，其中，启动用于到所述电话端点的电话通信的电话语音会话响应于向内电话通信。10.如权利要求1所述的方法，其中，启动用于到所述电话端点的电话通信的电话语音会话响应于应用程序接口请求以创建电话通信。11.如权利要求1所述的方法，其中，执行用于所述电话语音会话的电话操作包含在所述电话语音会话期间重定向到第二 URI。12.如权利要求11所述的方法，还包括:将应用层协议请求发送到由所述第二URI指定的第二应用资源；从所述第二应用资源接收第二响应，其中所述第二响应包括电话指令的第二文档；以及，根据所述第二响应的顺序处理的电话指令，执行用于所述电话语音会话的电话操作。13.如权利要求12所述的方法，其中所述电话语音会话的状态被嵌入在所述第二URI中。14.如权利要求13所述的方法，其中，收集的数字被嵌入在所述第二URI中。15.如权利要求1所述的方法，其中，执行电话操作包括处理所述响应的互联网内容类型及基于所述互联网内容类型确定电话操作。16.如权利要求15所述的方法，其中，处理所述互联网内容类型包括:如果所述响应包括电话指令的文档，则将内容类型设为第一类型，且如果所述响应是可播放的媒体文件，则将内容类型设为第二类型；并且其中执行所述电话指令包含:如果所述响应是第一类型，则在呼叫路由器处顺序地处理所述电话指令，且如果所述响应是第二类型，则在呼叫路由器处播放所述可播放的媒体文件。17.如权利要求16所述的方法，其中，包括无状态电话指令的可扩展标记语言文档的响应是第一类型，且包括音频文件的响应是第二类型。18.如权利要求1所述的方法，其中，所述状态信息至少包括初始电话端点、目标电话端点以及电话语音会话标识符。19.如权利要求1所述的方法，其中，根据所述响应在所述电话语音会话期间执行电话操作在呼叫路由器处无状态地执行。20.如权利要求1所述的方法，其中，执行电话操作包括:根据指定第二URI的电话指令，重定向到所述第二 URI ;其中重定向包含将应用层协议请求发送到由所述第二 URI指定的第二应用资源及将所述电话语音会话的状态信息嵌入所述请求中；接收所述第二应用资源的响应；以及根据所述第二应用资源的响应在所述电话语音会话期间执行电话操作。
【专利摘要】本发明涉及处理电话会话的系统和方法。在一个实施方式中，处理电话会话的方法包括：使用应用层协议与应用服务器通信；用呼叫路由器处理电话指令；以及创建可通过呼叫路由器应用程序接口(API)访问的呼叫路由器资源。在另一个实施方式中，用于处理电话的系统包括：呼叫路由器、用于应用服务器的URI、由呼叫路由器执行的电话指令、以及呼叫路由器API资源。
【IPC分类】H04M7/00
【公开号】CN104902113
【申请号】CN201510204607
【发明人】杰弗里·劳森, 约翰·沃尔斯, 埃文·库克
【申请人】特维里奥公司
【公开日】2015年9月9日
【申请日】2009年4月2日
【公告号】CA2720398A1, CN102027721A, CN102027721B, EP2266269A1, EP2266269A4, US8306021, US8611338, US8755376, US20090252159, US20100142516, US20130028251, US20130128882, US20140098809, WO2009124223A1
最新回复(0)