第四章用户目录，SIP和 Verto-CSDN博客

FreeSWITCH中的SIP和Verto都使用相同的用户目录机制和概念。FreeSWITCH的用户目录（简称目录）是与用户身份验证和授权相关的所有数据的配置中心。缺省安装完成后，FreeSWITCH已经提供20个用户，它们都使用缺省密码，每一个用户都隶属于一个或多个组。FreeSWITCH能够向特定用户或整个组发送呼叫。此外，在用户目录中，可以设置链接到用户或组的变量。然后FreeSWITCH在管理入局呼叫和发起出局呼叫时使用这些变量。我们将看到这些变量的用法，它们可用于选择出局电话提供商(ITSP)网关指定的用户或用户组；或让所有的话机隶属于同一个组，并在来电时让整组同时振铃；或者向CDR添加一些附加信息；甚至可以用于选择拨号方案的context。我们将描述如何添加用户和用户组。在SIP里，我们可以把话务发给一个网关（网关是指IPSP提供的服务器或其它内部服务），然后由网关负责话务路由和终止（比如说连接国内长途或国际长途的PSTN）。我们将描述如何设置网关，如何让我们的FreeSWITCH机器自动向远端服务器发起注册，并在发起出局呼叫时向其发送授权凭据。用户目录，SIP和 Verto

这一章，将涉及以下主题：

用户目录概念
FreeSWITCH的验证、授权和计账(AAA)
探索和使用示例用户目录
通过修改用户目录和拨号方案添加用户
SIP网关， DID 号码，拨号方案 Contexts 和 ITSP

用户目录概念

用户目录（可能是庞大而复杂的）是一份XML文档，它由FreeSWITCH和它的所有模块在需要用户相关信息时访问。用户目录中定义了用户的密码、所属于群组、与用户或组相关的各种变量和参数。

每当FreeSWITCH或其模块需要这类信息时，它会发出一个内部请求。这个内部请求会从诸多方法中选择一种，最终得到一个定义所需信息的XML片段。这个XML片段可以是一次数据库查询的结果，也可以是访问WEB服务获取的信息，还可以是从内存中的XML树查询得到的信息，这棵XML树是FreeSWITCH启动时加载硬盘中的XML配置文件构建的。

在本章中，我们主要从演示配置的缺省配置文件中查询用户目录。数据库查询或HTTP请求得到的用户目录信息，同样适用这些概念。

用户目录，或FreeSWITCH更通俗地称为“目录”的东西，通常具有以下模式：

一个"directory"包含一个或多个"domain"（译者注，这段里没有翻译的单词都是XML节点标签名），每个"domain"包含"groups"，每个"groups"包含一个或多个"group"。每个"group"包含"users"项，每个"users"包含一个或多个"user"项。"user"项包含"params"，一个"params"有一个或多个"param"项。XML作为可扩展的标记语言，模式实际上可能更复杂，我们将看到其中到处散布着"variables"和"variable"项，但你确实掌握了其中的诀窍。

顺便提一下，上面说了这么多XML标签项，其中只有"domain"和"user"是必须的。因此，最简单的完成目录XML树（或者mod_xml_cur返回的简片段）可能就是这样：

AAA: 验证、授权和计帐

"AAA"是一个缩略语，自远古时代起它就为电信老鸟所熟悉。特别是，它本身不但是PSTN运营的基础，也是早期拨号上网服务提供商的基础。

简而言之，AAA是：

身份验证—识别用户与它声明身份的一致性（比如登陆密码匹配）。
授权—识别用户拥有的“权限”（比如拨打国内长途、国际长途，不能拨打特别付费号码）。
计账—了解用户所做的事情和他的操作历史记录（例如：他的信用等级分是835，刚结束的通话费率是35个单位）。

正如您可以从这个增强的定义中看到的(更好的定义可以问谷歌)，AAA是一个非常抽象的需求，可以用许多不同的方法实现，用于许多不同的目标、业务逻辑和技术。它与计费不同，即使它向计费操作提供基本的会计数据，并且它本身也受到计费的影响(如果您不支付账单，您可能最终将不再被授权使用服务)。

在过去，RADIUS是AAA集成的主要协议和服务，现在仍然被很多ISP采用。FreeSWITCH支持RADIUS，可以集成在这样的历史环境中。

在演示配置实例中，FreeSWITCH以一种静态方式处理AAA，为公司内部PBX量身定制：

根据用户目录里的用户ID和密码检查验证身份。
根据拨号方案里的变量检查授权
以CSV文件或XML提供计账数据，前者方便电子表格或数据库直接处理，后者提供更丰富的数据维度，以便进一步阐述

探索并使用演示用户目录实例

FreeSWITCH安装完毕后，用户目录的主文件是/usr/local/freeswitch/conf/directory/default.xml。这个主文件包含许多其它文件。

让我们先理解其中最重要的几行：

Domains和groups

首先，设置域名"domain"。在SIP和Verto中，地址的格式是"userid@domain"，和email地址的格式很相似（事实上，SIP是从SMTP借鉴这个格式的，而Verto又从SIP借鉴）。可以配置多个"domain"，如果需要，可以在XML标签</domain>之后添加（截图中没有）。

接下来，定义一个"params"XML容器，包含了"domain"所属的"param"项。这些参数项，既会被链接到这个域所包含的"users"，也会被链接到"groups"容器中的"group"项（然后传递给"group"所包含的user"）。

有一个"param"的名字叫"dial-string"，它是非常重要，因为它定义了用户的联系方式，包括所用协议（SIP或verto等）和具体的通信地址。现在不需要费心去理解其中的细节。如你所见，截图实例中设置了一个SIP地址和一个verto地址，实际使用中，内部API知道用是否注册及注册的协议，如果注册，注册地址是什么。

接下来是另一个参数，允许verto协议与过程调用交互，用于会议管理等。

接下来定义了一个"variables"容器，它将被域中的用户创建或设置。我们在这里设置了许多有用的缺省值，这些值可以在拨号方案或用户组中的用户配置重写。

接下来是"groups"容器定义，它包含了一系列"group"项。其中一个group"名为"default"，其中包含了一个"users"容器，这个容器包含了default/子目录下的所有XML文件(/usr/local/freeswitch/conf/directory/default/*.xml )。这些XML文件会合理地包含定义"user"的XML片段，我们回头再说。

接下来可以看到其它"group"定义，每个"group"包含一个"users"容器，每个容器中包含几个"user"项。但在这些用例中，"user"项并没有定义用户相关的数据和变量，而仅仅是一个用户ID和一个”pointer”的类型声明，这说明，通过这个ID，可以用这个域的其它地方查找具体的用户定义。如果一个用户大多个组中兼职，这种机制是非常有用。比如，所有用户都是default"组成员，其中的一部分隶属于销售组，另一部分隶属于账单组。

用户

现在，让我们看一个真实的用户定义（不是"pointer"类型的）。进入/usr/local/freeswitch/conf/directory/default/目录，并打开1000.xml：

文件的开始处，同一个"user"标签的内部，定义了用户的ID（这就是前一节里，"pointer"类型用户声明要找的ID）。ID在一个"domain"域内是唯一的，一台FreeSWITCH可以服务于多个域，比如"domainA"和"domainB"。如果这两个域都有一个ID为"1000"的用户。那么这两个用户是完全独立的两个用户，彼此毫不相干。因此，这两个用户可能有不同的密码，可以同时拨打和/或接听两个电话，等等。他们完全不同的用户，他们恰好有相同的“ID”。它们之所以可以在同一FreeSWITCH，是因为它们归属于不同的域。因此，它们的完整地址是"1000@domainA"和"1000@domainB"，完全不同！一个FreeSWITCH平台同时处理多个域，电信术语叫“多租户”。

在"user"容器项内部和这一节的实例中，我们都可以看到一个"params"容器和一个"variables" 容器。

在"params"容器内，"param"项定义专属于这个用户的参数。这里的配置，会覆盖"domain"容器或"group"容器中的同名参数值。比如：之前domain定义中有一个"jsonrpc-allowed-methods"参数配置，你可以在这里重复配置这个参数，这时，这个特定用户将使用其自己的配置值而不是从域配置中继承缺省值。

其它选项中，你可以最希望修改的是"password"，显然，独立用户配置独立的密码和语音信箱密码（"vm-password"）有利于安全性（这两个密码的缺省值是在vars.xml里配置的）。

在某些场景下，可以方便地替换"dial-string"参数项。

“variables”容器和“variable”项的情况完全相同。在这里，你可能希望覆盖"default_gateway"值，这样特定用户可以使用自己指定的网关而不是缺省网关。此外经常需要个性化配置的还有"*id_name"、"*id_number"这些。

在这里，您可能希望覆盖“默认网关”，以便为此用户使用特定的SIP网关。经常需要个性化设置的还有“*id_name”和“*id_number”变量。

此外，你可能需要设置一些自己的变量。在演示配置示例中已经设置了一些，可以参考1000.XML到1019.XML。所有这些变量都可以在拨号方案和脚本中引用。例如，你需要检查一个用户可以发起哪种类型的呼叫，并为此设置了${toll_allow}变量，然后根据变量值选择逻辑。记住，所有这些变量对FreeSWITCH内核和所有模块都是可见的。因此，CDR模块也能引用它们，你可以在CDR报告中包含${callgroup}内容。

下表列出每个变量定义的用途：

Variable	用途
toll_allow	指定用户可以发起哪类型呼叫
accountcode	在CDR数据中显示的任意值
user_context	这个用户发起呼叫时，对应归属拨号方案的context
effective_caller_id_name	呼叫其他注册用户时，来电显示的名字
effective_caller_id_number	呼叫其他注册用户时，来电显示的号码
outbound_caller_id_name	向供应商发起出局呼叫时，设置的来电显示名
outbound_caller_id_number	向供应商发起出局呼叫时，设置的来电显示名
callgroup	可在拨号计划或CDR中使用的任意值

在演示示例中添加用户和拨号方案

用户定义在目录中，而电话路由规则定义在拨号方案中。在拨号方案中，有一些正则表达式检查变量的字符串模式。最常用的检查变量是"destination_number"，它的值是呼叫方所拨打的号码。

因此，如果我们在"directory"中添加了一个用户，我们必须保证拨号方案能够处理新添加的用户。这通常，但并非总是意味着我们也必须修改拨号方案。我们将在本章稍后的内容中了解这一点。

添加一个用户

演示配置的文件布局经过精心组织，这让添加/删除用户变得非常容易。在主文件/usr/local/freeswitch/conf/directory/default.xml中，定义了一个缺省的域，在这个域中定义了一个"default"组，这个组里有一条FreeSWITCH预处理指令，它读取/usr/local/freeswitch/conf/directory/default/目录下的所有XML文件，这些文件定义了各个具体用户。

缺省的演示配置中，预定义了20个用户，对应1000.XML到1019.XML的20个文件。此外还有其它一些XML文件，它们注释良好清晰，是灵感的源泉。

在演示配置中，添加用户很简单，复制一份1000.XML，让它变成1020.XML，然后编辑新生成的XML文件。在文件编辑器中，全文查找替换"1000"为"1020"。

就这样，我们仅在directory下创建添加了个文件，就创建了个新用户。新用户的所有属性配置都有1000用户一样：相同的"callgroup"、"toll_allow"等等。我们仅修改了用户的ID、语音信箱密码、"accountcode"和"effective_caller_id_name"，把它们的值变为"1020"。我们还需要重新加载配置文件，才能让FreeSWITCH认识新的用户，在命令行(fs_cli)上执行命令：

reloadxml

为新用户修改拨号方案

还有一个问题：前一章里，我们了解了拨号方案里的"Local_Extension"是如何定义的，并且知道了怎样根据"destination_number"路由呼叫。在缺省配置中，匹配的正则表达式是"^(10[01][0-9])$"，它精确匹配了1000到1019，而我们添加的用户是1020，怎么办？

有两种方法可选：第一种，修改现成的"Local_Extensions"，让它的匹配条件包含1020；第二种，干脆在拨号方案中创建一个新的extension。

我们可以拷贝"Local_Extension"片段（从开始标记"extension"到结束标记"/extension"间的内容）。我们可以修改新extension的名称属性，但这不是必须的。需要修改的是对"destination_number"的限定表达式，这里我们改成，"^1020$"，它将精确匹配"1020" 。

如果不想添加新的 extension。可以直接修改现存的"Local_Extensions"，让它的"destination_number"匹配表达式包含1020。有多种方式可以达成这个目的。缺省的表达式是"^(10[01][0-9])$"，它匹配1000到1019，我们可以把它改为"^(10[01][0-9]|1020)$"，这时它就能匹配21个号码，从1000到1020；或者范围放宽一点，改成"^(10[012][0-9])$"，这样它可以匹配1000到1029间的三十个号码。

同样的，我们需要重新加载配置文件来刷新拨号方案，命令还是reloadxml。

呼叫一个群组

在用户与群组那一节里，我们看到FreeSWITCH用户是可以属于一个群组的。此外，还看到了演示配置里是怎样配置群组的。在演示配置中，所有用户都是缺省群组成员，同时又可以把其中部分用户单独配置一个群组。但是，这仅是演示配置，这不是必须的配置，换句话说，缺省群组里可以不存在，也可以只配置一个成员。

用户群组的好处不仅在于方便配置变量和参数，而且可以把一个群组当成通话的被叫，同时桥接多个通话。

演示配置文件中，群组在/usr/local/freeswitch/conf/directory/default.xml文件里配置。让我们编辑它，添加一个新的群组，并测试呼叫组。

跳转到文件的尾端，在结束标记</groups>之前，插入一个新的"group"容器和需要引用的用户：

在我们的示例中，仅是拷贝粘贴"support"组，并编辑组名和引用用户列表，然后保存文件并从FreeSWITCH命令行发送"reloadxml"命令。

接下来，让我们在拨号方案中添加一个extension用于呼叫群组：编辑文件：

/usr/local/freeswitch/conf/dialplan/default.xml

定位到"group_dial_billing"，并拷贝一份粘贴到</extension>结束标记后。

接下来，修改extension名字、destination_number的匹配表达式，和传给"bridge"的参数。匹配"destination_number"的表达式改为"^2003$"，这样，如果呼叫"2003"，就会精确匹配到这个extension。传给"bridge"的参数，我们使用"group/groupname"结构组合，并引用${domain_name}变量，这样就可以向"tommaso_stella_fan_club"组的所有成员发起并行呼叫。顺便说一下，Tommaso Stella是意大利一名著名的水手。

不同的域可以配置相同的群组名（比如，在多租户的部署中，每个租户都有销售部），所以，我们需要引用domain_name变量，它标识的呼叫所属的域。

请注意，群组的成员（配置中的各个"user"项），最终是通过"dial_string"呼叫的，它可以全局的、域、组或用户级的参数。因此，呼叫群组时，连接各个成员的方式是五花八门的，比如成员一通过SIP呼叫，成员二通过Verto，成员三通过TDM，成员四同时并发上述三种协议。

在FreeSWITCH命令行上发出"reloadxml"命令之后，我们就可以拨打"2003"，让Tommaso Stella的所有粉丝都收到呼叫消息。所有的话机会同时振铃，只要某一位摘机应答，其它话机会立刻停止振铃。

Voicemail

演示示例配置的最佳特性之一是现成的语音信箱系统，它由mod_voicemail模块提供。在演示配置的拨号方案中，"Local_Extension"的最后四个action是：

<action application="bridge" data="user/${dialed_extension}@${domain_name}"/>

<action application="answer"/>

<action application="sleep" data="1000"/>

<action application="bridge" data="loopback/app=voicemail:default

${domain_name} ${dialed_extension}"/>

它们的含义是：尝试接通被叫（也就是说，对于dialed_extension，它派生自destination_number），如果失败（比如说30秒内无人接听），那么，系统自动发送应答消息，等待1秒，然后把话务接到voicemail 应用（这里用到了loopback“虚拟”终端）。

连接voicemail应用之后，呼叫方可以留言，FreeSWITCH足够智能，能够驱动被叫终端话机的MWI指示灯亮灯或闪烁。哇，这种魔力让我们这些电信极客们非常满意。(此外，当语音信息被提取或删除时，FreeSWITCH将关闭这些MWI。耶!)：

让我们看一下Jitsi上的一个使用实例，Jitsi是一个很好的自由开源软电话。如果被叫用户看到MWI提示，点击图中带有数字4的红色图标（表示MWI提醒有4条新的留言），她将会看到消息的一些细节信息，比如，其中的三条是新的留言：

如果她尝试听取留言，会触发Jitsi的一个Bug(Linux的V2.10.5550版)。当她点击蓝色的手柄图标时，事实上会回拨自己（也就是软终端呼叫自己的帐号）。如果她要听取留言，得使用FreeSWTCH提供的接入方式：呼叫*98或4000。系统首先会要求她输入语音信箱密码，演示配置中缺省密码和分机号相同（这里就是1011）。校验通过后，她将拥有一整套功能强大的语音邮件系统。当所有消息都被提取后，MWI图标将会消失。让我们看看拨打*98或4000后，检查自己语音信箱时的一些有用的菜单选项：

主菜单:

听取新留言
听取保存的留言消息

5-选项菜单(录制名字, 录制欢迎辞,管理欢迎辞，等)

#-退出语音信箱

听取留言信息时的菜单项：

1-从头开始重新播放留言

2-保存留言

4-倒带

6-快进

听取完一条消息后的菜单：

0-从头开始重新播放留言

2-保存留言消息

4-发送e-mail (要求配置e-mail地址)

5-返回

7-删除留言消息

8-转发留言消息

通过编辑XML文件/usr/local/freeswitch/conf/autoload_configs/voicemail.conf.xml，所有这些菜单都是可配置的，还可以配置更多！如果你不想修改，可以看看这个文件，你会了解到许多这里没有描述过的选项。此外，别忘记查阅我们的在线文档h t t p ://f r e e s w i t c h .o r g /c o n f l u e n c e，这里可以获取更多配置信息，比如语音信箱转电子邮件（以附件形式把留言信息发送到你的E-mail邮箱中），还有其它许多有趣的特性。

通过SIP网关和DID与整个世界通信

一切看起来都挺好的，但你真的希望这个漂亮的通信平台只能在内部注册用户间使用吗？

让我们看看怎样添加一个SIP网关来连接一个网络电信服务商（ITSP），这是扩展我们的通信平台，使它连通整个世界的最简单方式。ITSP为他们的客户提供SIP "trunks"服务，即将话务连接到世界上的电话网络的能力。此外，ITSP还会提供DID（Direct Inward Dialing，直接向内拨号）号码，我们的客户可以通过这个电话号码呼入到我们的通信平台。因此：SIP trunk是为我们向全世界发送电话而设计的；DID是用来接收来自世界各地的电话的。

SIP网关，从我们到ITSP，再到全世界

FreeSWITCH通过网关（"gateway"）概念为我们简化了SIP。FreeSWITCH术语“网关”只是为我们提供了一个美化的自动化工具，让我们可以用一种简单的语法完成一系列复杂的工作：检查特定的ITSP是否可用，向它发送出局呼叫，必要时登录ITSP，获取认证与授权，等待ITSP把我们的话务连接世界。

所有这些机制和响应对我们来说都是透明的，即使我们不使用，对IITSP的可用性监听也是例行的，所以如果ITSP关闭服务，我们甚至不会尝试向它发送呼叫消息，但在它恢复服务后又能够使用它。

顺便说一下，实际上FreeSWITCH是利用SIP的代理（"proxy"）概念来请求ITSP路由我们的出局话务的。然后，ITSP使用一些对我们来说不透明的方式让话务抵达终点，比方说把我们的话务直接连接给最终的终端。可能是ITSP与最终或中间运营商的直接链接；也可能是ITSP与PSTN硬件接口，比如说Sangoma的板卡和Patton的盒子；也可能是我们的ITSP直接把话务路由给上游的ITSP。这些我们都不知道，也不需要知道。

每个ITSP接收请求和处理路由的方法略有不同。ITSP必须认真对待安全问题。我们必须是非常认真地对待与ITSP间连接的安全性，这有可能导致数千美元的盗打。这很容易理解，其他人，比如一个流氓ITSP，盗用我们的账号，把别人的话务路由给我们的电话供应商，最终却需要我们支付账单，而且这个费用可能是是非常惊人的。因此，在设置第一个网关之前，让我重复一遍:我们必须非常认真地对待安全问题，防止欺诈。

电话诈骗是一个庞大的行业，持续发生的诈骗数量之多令人难以置信，而且肯定会有人为此付出代价。保证我们的密码强度和不可猜测性，要求我们的ITSP核实我们的IP授权，设置目的国家的白名单（即只能拨打被授权的国家号码，比如允许拨号美国、欧洲和亚洲号码，但不能拨打大洋洲和卫星电话），阻止其它付费号码（比如188）。如果可能，全部使用基于TLS和SSL加密的SIP通信，确保只有我们发起的呼叫才能被ITSP接受并处理。让我们假设，我们已经尽了最大的努力做好了尽职调查，确保自己不受欺诈。

编辑/usr/local/freeswitch/conf/sip_profiles/external/example.xml XML文件，并在</include>标记符号前添加一个"gateway"容器。我们可以在http://freeswitch.org/confluence上搜索FreeSWITCH文档，查看ITSP网关的示例配置，或者查看ITSP网站，向ITSP的支持发送邮件，或者在FreeSWITCH邮件列表中询问。总之，通常很简单，归结起来就是用户/密码对，是否需要注册。我们的示例中将会使用Telnyx，2017年ClueCon会议（我们的交流大会，每年8月在美丽的芝加哥召开）的赞助商之一。

首先，在Telnyx创建用户名和密码。我们新创建的用户名是"freeswitchuser"，它的密码是"huikyfruywedgweicguwy"。接下来，继续完成之前未完成的编辑，打开/usr/local/freeswitch/conf/sip_profiles/external/example.xml XML文件，在</include>标记符号前添加一个"gateway"容器：

就是这样，我们可以重启FreeSWITCH，或者在命令行发"reload mod_sofia"命令，FreeSWITCH将会自动注册到Telnyx SIP代理服务器，我们已经准备好把话务发送到外边的世界。

我们可以通过"sofia status gateway telnyx"命令来检查新网关的运行状况。

现在，我们可以看到我们的配置已经成功注册（"State"那一行的值是REGED"），还可以看到这个网关运行61秒了，将在1小时后刷新注册，当然，还有其它信息：

现在，为了让我们能够通过Telnyx网关拨打电话，我们还需要修改拨号方案，打开/usr/local/freeswitch/conf/dialplan/default.xml文件，在文件的头部，添加一个新的extension，作用是通过Telnyx 网关连接美国的PSTN网络：

看一下"destination_number"匹配的正则表达式定义：必须以9打头，第二位是1，然后接着10位数字。在"destination_number"正则表达式中，我们用圆括符括住了首位9后面的内容（剥离前缀9）。我们将在下一行用到选择的内容，在传递给"bridge"的"data"参数中，这一串值将替换"$1"占位符（"$1"表示取第一对圆括符所包含的内容。如果有第二对圆括符，我们可以用"$2"占位符引用其内容，以此类推）。

执行"reloadxml"命令后，我们可以通过一台注册话机拨打918005551212，然后，通过Telnyx连接18005551212（拨号方案中，剥离了前缀9）的美国号码。

SIP DID，从世界其它地方到ITSP，再到我们平台

一个DID（Direct Inward Calling，直接向内呼叫）号码是一个电话号码，从某种意义上来说，拨打这个号码，将会向一个SIP服务器发起一通呼叫（在我们的示例中，这个SIP服务器就是FreeSWITCH），然后这个服务器会把话务跟帖到它的最终目的地，通常是一个内部分机。

呼叫的逻辑流程是：

CALLER -> PSTN -> DID -> ITSP -> SIP -> FreeSWITCH

DID提供商有很多，最著名的纯DID提供商可能是DIDx.net，他们可以提供世界各地的本地号码接入。许多ITSP也可以租用号码，提供他所在国家的本地号码或国际长途号码，他们通常通过上游的DID提供商得到这些号码。

因此，我们从ITSP购买（实际上是租用，没有人实际出售电话号码的所有权，你只能按月支付使用费）一个本地号码，在本书实例中，从Telnyx购买。我们选择一个美国芝加哥的号码。Telnyx足够智能，它会使用我们FreeSWITCH网关注册时携带的数据（我们的IP和端口），把拨打我们所购号码的电话送到这个地址上。我们买到的DID号码是"+1-872-203-0716"。我们需要在入局的"public"拨号方案中添加一个extension（"public"是拨号方案中用于接收外部呼叫的context），然后才能接收来自Telnyx的呼叫，这些呼叫的目的号码是我们的DID号码。编辑/usr/local/freeswitch/conf/dialplan/public.xml文件，在头部添加一个名为"telnyx_did"的extension，我们把入局的呼叫转接给缺省拨号方案中的1012分机（我们之前了解过的"Local_Extension"，它提供了许多特性访问，包括语音信箱）。

在FreeSWITCH命令行发出"reloadxml"命令后，我们可以用手机拨打"+1-872-203-0716"，最终，电话会被路由给注册"1012"的软电话用户。软电话会振铃，如果没人接听，会转到语音信箱去留言。

SIP和Verto Profile, 拨号方案Context, ITSP

在前一节中，我们编辑了拨号方案的"public" context，提供呼叫DID号码的接入服务。在更前一节中，我们在SIP的"external" profile定义中添加了一个ITSP网关，并在拨号方案的"default" context中添加了一个extension，让我们的平台可以通过网关连接外部世界。

实际上，在演示配置示例中，我们有两个SIP profile，它们被命名为"internal"和"external"（这些名字没有特别含义，你可以随意更改），此外，还定义了两个主要的拨号context，命名为"default"，和"public"（此外，还有一个context叫features"，但这里与它不相干）。

一开始似乎有点困惑，但这是完全有道理的。继续阅读。

SIP Profiles

一个SIP profile仅是FreeSWITCH监听的一对地址/端口。

假设我们的服务器IP是194.20.24.11。演示配置中，"internal" SIP profile让FreeSWITCH监听5060端口。那么，"internal" SIP profile就是监听194.20.24.11:5060的服务。这是处理内部呼叫、注册、鉴权的IP和端口。此外，在"internal" SIP profile定义中，有一个参数项名叫"context"，它的缺省值是"public"。所有抵达这个地址/端口的呼叫都会被路由到拨号方案中的"public" context。

演示配置实例中的external" SIP profile监听的是194.20.24.11:5080。这个地址是给我们连接ITSP用的，它们把电话发到这个地址上（通常ITSP是不发注册的，他们只发呼叫）。因此，如果你需要在ITSP那边显式地设置地址，记住要设置"external" SIP profile的端口，也就是演示配置中的5080。同样，在"external" SIP profile定义中，也有一个参数项叫"context"，它的值缺省是"public"。抵达这个地址/端口的呼叫都会被路由到拨号方案中的"public" context。

哎哟！怎么了？两个SIP profile都使用"public"拨号方案context，但我们之前看到，内部用户和呼叫由拨号方案中的"default" context提供服务。这是怎么回事？我们一会儿再看。

拨号方案Context

在拨号方案中，"public" context所包含的extension都是可以让外部世界和未授权用户安全访问的。这些extension不会访问昂贵的付费服务或可利用的特性。

它只提供很少的特性和extension，只够把入局呼叫连接到一个内部话机，或提供类似语音信箱的或IVR服务。而且，它通常以一种绝对和最终的方式提供这类特性或服务----把通话转接到拨号方案中"default" context的一个extension。前面我们讲述过把一个DID呼叫转接到内部1012分机的实例，这个1012是XML拨号方案的"default" context中定义的（演示配置中，拨号方案模拟始终用XML配置）。入局电话不能到处转悠，只能转接给一个绝对的实体。

拨号方案中，"default" context中定义了大部分操作的演示实例，并为通过授权的内部用户提供服务。当一部话机连接到"internal" SIP profile注册时，需要提供用户名和密码进行鉴权。它们将与用户目录中的配置核对。如果用户授权成功，那么它将与用户目录中定义的所有变量和参数关联，还有群组和所属域配置信息。

在演示配置文件中与通过授权用户关联的变量与参数中，我们可以找到一个叫"user_context"的变量，它的值被设为"default"。就是这样，内部话机作为用户注册，并根据用户目录中的配置检查凭据。授权成功后，如果用户目录中，这个用户有定义"user_context"变量，那么，这个用户（这部话机）所发起的呼叫，将会被路由给变量值指定的context（覆盖SIP profile中配置的context）。

Verto Profiles和拨号方案Context

在演示配置实例中，Verto总是要求对注册的话机（浏览器）进行鉴权。因此，它的行为和"internal" SIP profile相似："user_context"变量关联到授权通过的用户上，这个用户（浏览器）发起的呼叫将被路由到变量值指定的拨号方案context中。

因此，如果我们的ITSP通过SIP协议向我们的FreeSWITCH平台发起一路呼叫，DID呼入配置可以路由给一个通过授权的，已注册的Verto WebRTC客户端用户。同样的，授权后的Verto用户，可以通过WebRTC浏览器发起呼叫，呼叫将由拨号方案的"default" context处理，可以通过SIP网关连接外部世界。这是实现一个完整功能的SIP/WebRTC网关的最简单方式。

ITSP

我们的网络电话服务提供商（ITSP），会把拨打DID号码的电话发送到我们的"external" SIP profile（演示配置中的5080端口）。我们将使用"external" SIP profile来发送出局呼叫给ITSP，连接外部世界。在拨号方案中，我们将用一种"gateway"封装的语法来处理连接ITSP可能需要的鉴权过程。

总结

这一章，我们讨论了下列主题：

FreeSWITCH是如何实现AAA (认证、授权、计账) 这些概念的
FreeSWITCH是如何将用户收集到一个目录中的
FreeSWITCH是如何利用用户目录信息和拨号方案路由用户间和出局的呼叫
试用各种功能特性，比如语音信箱
添加一个新用户并修改相应的拨号方案
通过网关连接外部世界
SIP 和 Verto profile

在这一章里，我们修改了缺省的XML拨号方案，学会了怎样在XML用户目录中设置用户和域。此外，还了解了怎样通过SIP网关和DID号码连通外部世界。下一章，我们将初步接触WebRTC和Verto，一种强大的技术，它承诺我们的FreeSWITCH通信平台可以无缝地和浏览器、移动应用、物联网(IoT)对接。