Browsed by
Category: miniSipServer云通信

miniSipServer云通信产品

优化「连选组」业务

优化「连选组」业务

「连选组」是一项非常古老的企业通信业务,在电路电话时代就有广泛的应用, VoIP 时代也仍然有大量的企业部署该业务。然而时代毕竟变了,业务本身也需要与时俱进,适应 IP 网络的特点和要求。我们依据最近客户的需求和网络环境的变化,对 miniSIPServer 的「连选组」业务做了一些优化。

主要是对业务中的「话务员」特性进行修改和优化,请参考下图:

连选组话务员配置

修改一:一位话务员可以同时配置在多个连选组中。以往限定了一位话务员只能配置在一个连续组中,这已经不符合现代企业的要求。企业中有些员工往往承担复合性工作,因此有很大可能需要同时支持多个连选组,新特性适配了这个需求。

在电路电话时代,话机终端缺乏足够的能力,因此通常「连选组」会允许话务员拨打特定的电话登录、或者登出连选组。出于以下几方面的考虑,miniSIPServer 新连选组业务不再支持话务员登录、登出操作:(1)如今的 SIP 终端多数都具备足够的能力,可以在终端侧实现「免打扰」等功能,因此没有必要再手工登录或者登出。(2)一位话务员同时支持多个连选组后,简单的登录、登出无法满足需要,需要修改为针对特定的连选组进行操作,拨号变得繁琐而没有必要。

修改二:如果连选组的组策略是「线性策略」,我们可以指定话务员的顺序号,从而设定话务员被选择的顺序。以往是按照话务员登录系统的先后顺序默认为组的选择顺序,其实就是随机顺序,这无法满足目前的需求,实际情况中有些话务员在组内的优先级别总是会有差异。话务员设定的「线性策略顺序号」越小,则越先被连选组选中。如果顺序号相同,则以登录系统的时间进行排序,先登录的优先被选择。

当然,这个新配置项对「轮选策略」无效,「轮选策略」总是尽量均匀地选择话务员,均匀分配工作量。

本地 miniSIPServer 和 云 miniSIPServer 的「连选组」业务都已经更新。业务的配置和使用都没有差异,请参考业务文档了解更详细的信息。

安全的企业 SIP 通信

安全的企业 SIP 通信

企业内部的通信系统一般部署在私网内部,在网络边缘部署 SBC 或者语音网关与外部进行通信,因此大部分场景下企业通信都很安全。然而越来越多的企业在云端部署 SIP 服务器,而企业内部的 SIP 终端也越来越多地从外部网络接入企业 SIP 服务器,这使得部分(或者全部)企业通信系统暴露在公共网络中,安全问题日益严重。

企业 SIP 通信安全涉及网络系统的许多方面,例如防火墙等。仅就 SIP 通信本身而言必须加密,避免将通信信息暴露给其他网络用户。加密的 SIP 通信包含两个部分:(1)SIP 消息(信令)加密,以及(2)语音流(RTP)加密,如下图所示:

SIP 加密通信网络拓扑

当然,企业可以部署 VPN 将整个网络系统(不仅仅是通信系统,也包括办公系统等)进行加密,加密的 SIP 通信也可以建立在 VPN 之上。建立企业 VPN 成本比较高、系统比较复杂,本文仅讨论加密的 SIP 通信,不涉及VPN 等其他网络安全技术。

SIP 消息的加密通过「SIP over TLS」实现,云 miniSIPServer、本地 miniSIPServer 以及 miniSIPPhone 都支持 SIP over TLSv1.2 / TLSv1.3。请参考在线文档,本文不再赘述。

语音流通过 SRTP 传输实现加密,SRTP 的 master key 和 master salt 通过 SIP 消息的 SDP ( RFC4568 )传输、协商,因此 SIP 消息加密才能确保 SRTP 的关键信息不会泄露,仅仅 SRTP 传输加密语音流、但是明文传递 SIP 消息,不能确保整个 SIP 通信的安全性。

RFC4568 中定义了几种加密套件,目前我们选择支持默认的 AES_CM_128_HMAC_SHA1_80 ,暂不支持其他加密套件。

SRTP 协议族包含诸多扩展,目前 miniSIPServer 和 miniSIPPhone 支持最基础的 RFC3711 协议,这也是绝大多数 SIP 设备(包括服务器、PBX、SBC 以及终端)都支持的基础 SRTP 协议。目前不支持 DTLS-SRTP,主要考虑以下几点:(1)SIP over TLS 已经可以确保 master key & salt 的安全性,与 DTLS 的作用等效;(2)虽然 WebRTC 等互联网技术广泛采用了 DTLS-SRTP,但大部分 SIP 设备并不支持 DTLS-SRTP,在企业 SIP 通信领域会有互联互通的问题。

miniSIPServer 和 miniSIPPhone 默认可以选择 SRTP,无需额外的配置。部分 SIP 设备需要明确配置是否选择 SRTP,例如 MicroSIP 在配置账号时,「Media Encryption」需做以下设定:

MicroSIP 配置 SRTP
上传 IVR-XML 以及语音文件

上传 IVR-XML 以及语音文件

miniSIPServer 云允许用户定义自己的 IVR-XML 文件以及相关的语音文件,以满足用户自己公司 IVR 业务的特定要求。但是这些文件需要发送给我们的支持团队,帮助上传到用户的虚拟服务器中。

这确实有点繁琐,也非常不方便。

因此我们最近更新了云系统,允许用户自己上传 IVR-XML文件以及语音文件到虚拟服务器中。请点击菜单“账户 – IVR-XML 文件(或者语音文件)”完成操作即可。

当然, IVR-XML 文件必须遵循 IVR-XML 技术规范的要求,而语音文件也必须符合 miniSIPServer 语音编码要求。

电话号码URI

电话号码URI

众所周知 VoIP 域(SIP域)采用 SIP URI 建立呼叫对话。如果需要连接传统的 PSTN 电话网络,我们需要部署 VoIP 网关(或者 SBC 会话边界控制器)用于桥接两个不同的网络。大部分网关都支持 SIP URI,因此我们采用 SIP 中继连接 SIP-PSTN 网络时,与连接 SIP-SIP 网络并没有什么不同。

但有些网关并不支持 SIP URI,它们仅能支持传统电话号码格式的URI(RFC3966规范定义了这种 TEL URI格式)。这种 TEL URI 采用<tel:xxx>格式,而不是<sip:name@address>格式。请参考下图:

电话号码URI网络

以前版本的 miniSIPServer 总是能接受对方发起的 TEL URI 格式的呼叫,但是 miniSIPServer 本身并不会发起这种格式的呼叫。最近几个月先后有几位客户向我们反馈,希望 miniSIPServer 能支持采用 TEL URI 格式发起SIP 中继呼叫,以便和传统 PSTN 网络的网关进行对接,因此我们升级了 miniSIPServer (V60 build 20250208)扩展 SIP 中继的功能。在 SIP中继的“出呼叫”配置中,可以选择“采用电话号码格式”,miniSIPServer 据此将采用<tel> 格式发起呼叫,如下图配置所示:

miniSIPServer 中继“出呼叫”配置电话号码格式

对于 SIP 中继的入呼叫,无需任何改变,miniSIPServer 可以接受对方采用 SIP URI 或者 TEL URI 发起的呼叫。

会议室以及其他

会议室以及其他

近日 miniSIPServer 升级到V60版本,这是最新的、可用于商业部署的稳定版本。第一个重大特性就是“会议室”业务,该业务支持不超过 5 个本地分机用户的会议呼叫。请参考业务文档了解细节。miniSIPServer 云也同步升级支持该业务。

另外,正如我们在前一篇博客中提到,V60 业务最终移除了部分老旧的业务,例如呼叫卡、话吧。这些业务曾经对我们某些特定的客户非常重要,但就目前而言该对这些业务说再见了。

支持 TLSv1.3

支持 TLSv1.3

我们最近更新了 miniSIPServer 以支持 TLSv1.3。本次修改不影响配置,如果您升级 miniSIPServer 到最新版本,无需修改任何配置。

miniSIPServer 有两个模块有可能用到 TLSv1.3:(1)SIP 服务器模块;以及(2)嵌入式 HTTP 服务器模块。如果您的 SIP 话机(或者软电话)支持 TLSv1.3,那采用这个协议将能更好地保护您的通信。请参考《基于 TLS 的 SIP》了解更多细节。目前本地 miniSIPServer 和云端 miniSIPServer 都可以支持基于 TLSv1.3的 SIP 通信。

本地 miniSIPServer 采用内嵌式 HTTP 服务器提供 web 管理,默认没有加密。如果您需要或者希望通过公共网络管理、配置 miniSIPServer,那么建议启用加密传输的 HTTP 服务。目前主流的浏览器,例如Chrome、Edge、Firefox 等,都支持 TLSv1.3,请参考《Web 管理》配置和启用加密的HTTP。

181 Call Is Being Forwarded

181 Call Is Being Forwarded

“呼叫前转”是 VoIP 以及通信领域非常传统的业务。默认一般是由 SIP 终端(话机)发送 3xx 消息给 miniSIPServer 进行呼叫前转,当然 miniSIPServer 自身也可以直接发起呼叫前转。

大多数情况下,主叫侧并不知道被叫侧发生了呼叫前转,主叫侧也并不关心被叫侧的呼叫是否被前转了。然而,有些时候主叫侧确实需要知道被叫侧的呼叫前转。

miniSIPServer 目前会向主叫侧发送 181 Call Is Being Forwarded 消息,明确告知主叫:被叫侧正发生呼叫前转。在 181 消息中,miniSIPServer 增加了一个 Call-Info 头域携带前转的必要信息。请参考下图:

呼叫前转流程中的 181 消息及 Call-Info 信息

上图的流程发生了两次前转:(1)被叫 B 被前转到被叫 C;以及(2)被叫 C 被前转到被叫 D。

181 消息的 Call-Info 头域将携带以下信息:(1)呼叫正在被前转;(2)谁发生了呼叫前转;以及(3)前转呼叫的目标用户。请参考上图第一个 181 消息(即被叫 B 前转到被叫 C)中的 Call-Info 头域细节:

Call-Info: purpose=forwarding, username="userb", contact="userc"
外线的 RequestURI 参数

外线的 RequestURI 参数

miniSIPServer 与 VoIP 服务器(网关)通过外线连接,发送消息(例如 REGISTER 或者 INVITE等消息)时会在 Request-URI 中自动附加参数“user=phone”。这是来自中国移动的要求。多数情况下这种做法都没有问题,在 RFC3261 规范中也明确定义了 RequestURI 的附加参数。

然而事情总有意外。最近有些客户向我们反映,miniSIPServer 与他们的 VoIP 服务商网络对接失败,对方服务器无法识别 RequestURI 的参数。当然,简单的方法自然是这些服务商升级自己的服务器,遵循 RFC3261 标准规范的定义,这样大家都会很舒适。

其中个别运营商坚持目前的状态,不愿意做出任何改变。那怎么办呢?我们不得不在外线的配置做出一点修改,请参考下图:

外线的 RequestUR 附加参数配置

我们在外线的“出呼叫”配置中,增加了一项“Request-URI 附加参数”。客户们可以根据自己的网络状况来设置该项的值。

需要说明的是,如果是中文界面,我们默认客户是在中国的网络环境下配置外线,因此该项的默认值是“user=phone“,而其他语种的界面中,该项默认为空。我们认为这样的处理可以满足全球各种网络环境的要求。

该修改已经应用于本地版本的 miniSIPServer 以及云端版本的 miniSIPServer,欢迎大家试用。

miniSIPServer 新 web 界面

miniSIPServer 新 web 界面

我们最近更新了 miniSIPServer 产品的 web 管理界面,包括本地 miniSIPServer 产品以及云端 miniSIPServer。新界面更接近本地 miniSIPServer 的图形管理界面,请参考下图:

miniSIPServer 新 web 管理界面

我们希望新界面能帮助已经熟悉本地图形界面的 miniSIPServer 用户,这些用户在面对“熟悉”的界面时能快速体验云端 miniSIPServer。

Request-URI 的附加参数

Request-URI 的附加参数

SIP 网络默认采用 SIP URI 传递信息,例如 From、To等消息头,格式如下:

sip:+8613901088888@ims.bj.chinamobile.com

传统的电信网络一般都是采用 E.164 格式的电话号码,这种格式与 SIP URI 有很大差别,因此 ETSI(3GPP)定义了一种新的 URI,即 TEL URI,格式如下:

tel:+8613901088888

因此在连接电信运营商的 IMS 网络时,通常可能有两种 URI 格式: SIP URI 以及 TEL URI。miniSIPServer 可以支持这两种格式,能够自动处理入呼叫的 TEL URI 格式,但是 miniSIPServer 自己在发出呼叫时,总是采用 SIP URI 格式。

这里有一点问题。幸运的是 IMS 网络考虑非常仔细,例如中国移动可以接受 TEL URI 以及带有特殊参数“user=phone“ 的 SIP URI,格式如下:

sip:+8613901088888@ims.bj.chinamobile.com;user=phone

如果我们配置”外线”连接中国移动的网络,事情就很顺利,因为 miniSIPServer 在外线的呼叫中会自动给 Request-URI 添加“user=phone”。但是在某些市场(区域),中国移动要求采用 SIP 中继的连接方式,这就会导致问题。 miniSIPServer 在中继呼叫中不会对 Request-URI 添加上述参数,因为这种场景我们认为是“服务器 对 服务器”的模式。

为了解决这个问题,我们在 SIP 中继的“出呼叫”配置中增加了“Request-URI 附加参数”项,请参考下图:

Request-URI 附加参数配置
Request-URI 附加参数配置