Browsed by
Category: miniSipServer云通信

miniSipServer云通信产品

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 附加参数配置

临时响应的可靠性

临时响应的可靠性

众所周知,RFC3262 协议定义了 SIP 临时响应消息的可靠性。这是个非常古早的特性,miniSIPServer(无论是本地版本,还是云端版本)在很久以前就已经支持这个特性。在与传统电信运营商的 IMS 网络对接时,往往必须要支持可靠的临时响应消息,如果设备不具备此能力,运营商通常会直接拒绝所有的呼叫。

RFC3262 定义了“100rel”参数来指示临时响应消息的可靠性,因此我们在此将其称为“100rel”能力。通常情况下,主叫在发起呼叫时应明确指示出自己是否支持“100rel”能力,被叫也同样需要明确要求采用“100rel”能力,因此呼叫双方才能建立临时响应消息的可靠性。

启动100rel能力的基本呼叫流程

在 RFC3262 标准中,我们可以明确以下细节:

…… the initial request contained a Supported or Require header field listing 100rel, and that there is a provisional response to be sent reliably. ……

UAS core … MUST contain a Require header field containing the option tag 100rel, and MUST include an RSeq header field.

上图描述了可靠临时响应消息的基本流程。UAC 在收到可靠的临时响应 18x 消息时,应当向 UAS 方发送 PRACK 消息,告诉 UAS 自己已经收到了 18x 消息。

这不是一个很复杂的流程,我们一直都认为如此。然而几天前一位云通信用户向我们反映,他无法呼叫外部电话。我们跟踪了他的呼叫,得到以下图描述的呼叫流程:

在 100rel 流程中收到 405 错误消息

难以置信…… 这家 VoIP 运营商升级系统后,在 183 消息中要求采用“100rel”能力确保临时响应的可靠性,然而在 miniSIPServer 发送 PRACK 消息进行确认时,它居然返回“405 method not allowed”。这种情况下当然会导致所有的外呼呼叫都失败了。

这是为什么?!如果不能接受、或者不支持 PRACK 消息,它为什么在临时响应消息(也就是183消息)中明确要求“100rel”呢?

要解决这个问题本来也相当简单。只要在临时响应消息中移除“100rel”、即不要求可靠性保证即可,那样 miniSIPServer 就不会发出 PRACK 消息。但是不幸的是,这家运营商的团队居然不知道该怎么做。

我们的客户就被耽搁在这了,他的业务被迫停滞下来。另一方面,我个人猜测这家(以及某些)运营商采用了开源的服务器,例如 Asterisk、FreeSwitch 等,来构建自己的解决方案,但是他们也许没有足够的专家来理解自己究竟构建了什么。

因此我们更新了 miniSIPServer,在外线的配置中增加一个选项用于关闭“100rel”能力,如下图所示:

关闭临时响应消息的可靠性

一旦勾选了这项, miniSIPServer 向外线发出 INVITE 消息时,将不会再携带“100rel”参数。如果您对接了类似荒谬的运营商,请试试这个选项。

拒绝使用某些免费电子邮件地址

拒绝使用某些免费电子邮件地址

最近有很多客户向我们反映,他们收不到注册账号时系统发送的激活邮件。大部分客户使用的电子邮件都是来自某些免费的邮件系统,例如 gmail、163等。

起初我们认为这些系统将我们的激活邮件转移到“垃圾”分类中去了,但是客户们在那也没有找到相应的邮件,因此我们判断这些电子邮件系统拒绝了来自我们的邮件。

我们完全可以理解这些系统的处理方式。 我们的系统会发出大量的邮件,包括激活邮件、账户余额提示邮件等等,这些系统可能据此将我们判定为垃圾邮件发送者。

这让我们很困扰,而且我们实在不愿意这样,因此我们决定不再接受用免费邮件地址来注册 miniSIPServer 云系统的账号。我们希望我们的系统被视为严肃的云通信系统,当然我们也衷心希望客户们能理解这点。

优化:将IVR-XML文件装入内存

优化:将IVR-XML文件装入内存

在多数语音交互的场景中, IVR-XML 文件都比较小,通常是几KB,因此收到呼叫触发 IVR 业务时,服务器都会从硬盘读取 IVR-XML 文件并触发相应的 IVR 流程。但是,如果负荷非常大,例如有大量的并发呼叫同时触发大量的 IVR 流程,miniSIPServer 将频繁读取硬盘上的 XML 文件。显然,这实际会影响服务器的性能。

因此我们做了点优化,将所有的 IVR-XML 文件都装入内存。如果这些文件没有被修改,IVR 业务就直接从内存中读取 XML 文件的内容。如果文件被修改了,miniSIPServer 会自动将修改后的 XML 文件再次装入内存。

这就意味着所有的 IVR 操作都是访问内存,不更改文件的情况下,不会再访问硬盘,miniSIPServer 运行比以前要快一些,在负荷沉重的时候尤其如此。

转发视频流

转发视频流

如果您使用以前版本的 miniSIPServer,如果想让 miniSIPServer 转发媒体流,miniSIPServer 只会转发语音流而去掉视频流。

这主要是因为视频流会占用太多的带宽,同时也要求服务器有足够的计算能力。很多设备实际上达不到这样的要求。但是越来越多的客户要求我们改进这点,在转发语音流的同时也转发视频流,因为他们的设备目前已经足够强大,而且网络也有足够的带宽。

既然如此,这个要求似乎非常合理,因此我们认为应当升级 miniSIPServer 满足这些客户的需求。

因此最新版本(20210604 构建版本)正式发布,这个版本在转发媒体流的时候,将同时转发语音流和视频流。

升级版本后无需更改配置,您唯一要注意的是硬件的计算能力和网络的带宽是否满足需求。

例行维护

例行维护

数据中心通知我们将进行例行维护,会影响到我们虚拟服务器所在的部分物理主机服务器。这些主机将会安装一些紧急补丁并重启。

计划的维护时间(UTC时间格式)如下:

2020-08-07 03:00:00 上午 UTC

请注意以下几点重要信息:
(1) 维护窗口预期大约是2个小时,然而实际下线时间可能是45 ~ 60 分钟。
(2) 您的虚拟服务器将关闭,维护期间将无法访问。
(3) 虚拟服务器重新工作后,您可能需要重启 SIP 电话或者本地的 SIP 设备(例如网关)。

如果您有任何问题或者关注,请通知我们。感谢您的耐心和配合!谢谢!

在“语音邮箱”业务中使用个性化语音

在“语音邮箱”业务中使用个性化语音

由于云端miniSIPServer和本地miniSIPServer是基于同样的核心构建,因此 一般情况下大部分业务特性是相同的。有一些业务,由于某些条件的限制,有部分特性会有一些差异,比如“语音邮箱”业务。

本地miniSIPServer系统中,分机用户可以设置不同的留言语音提示,而在云端miniSIPServer系统中,每个虚拟系统有统一的留言提示音,分机只能使用系统统一的提示音。用户仅能替换这个统一的留言提示音,不能为每个分机单独设置不同的提示音。

最近我们升级了云端miniSIPServer系统。在云系统中,每个分机现在也能配置和使用不同的留言提示音。请参考下图,在分机的配置中,新增了“个性化语音ID”项,每个分机可以配置不同的语音ID,也就是可以使用不同的留言提示音。

语音留言提示音配置
语音留言提示音配置

当然,目前云系统用户仍然无法自行将语音上传到虚拟服务器。如果您要上传语音,请将语音文件发送给我们的技术支持团队,我们将手工将您的语音文件上传到虚拟服务器中。

语音文件上传后,您可以在管理界面中自行进行管理。请参考下图所示:

语音资源管理
语音资源管理

另一方面,您需要按照一定的规则要求创建语音文件,包括文件的格式、语音编码要求,等等。请参考在线文档了解更多细节。