Browsed by
Tag: SIP

Chrome/Firefox 用 WebRTC 向 SIP 发起呼叫

Chrome/Firefox 用 WebRTC 向 SIP 发起呼叫

新近发布的 miniSIPServer (V70 build 20250402)支持一个很有趣的特性:我们可以用浏览器(必须支持 WebRTC 技术,例如 Chrome、Firefox 等)向 miniSIPServer 发起呼叫,呼叫 SIP 域的设备(电话、网关等)。网络拓扑如下图所示:

语音媒体流采用端对端加密方式通过 DTLS-SRTP 传递,与 miniSIPServer 连通。目前仅支持语音通话,不支持视频通话。

浏览器 Web 侧采用简化版的信令(MCCP,miniSIPServer Call Control Protocol,即 miniSIPServer 呼叫控制协议)控制呼叫,并通过加密的 Websocket 连接( WSS,Websocket secure)与 miniSIPServer 对接。目前仅支持 Web 域向 SIP 域发起呼叫,不支持反向由 SIP 域向 Web 域发起呼叫。

我们在浏览器中输入以下 URL 即可从浏览器向 SIP 域发起呼叫(演示分机用户100 呼叫分机用户 101):

https://www.myvoipapp.com/miniwebphone2/lite.html?server=192.168.3.70&clr=100&pwd=100&cld=101

URL 类似命令行方式,其中各项参数说明如下:

(1)「https://www.myvoipapp.com/miniwebphone2/lite.html」是一个简单的页面,加载到浏览器后即可与指定的 miniSIPServer 服务器建立 WSS 连接,并发起呼叫。我们可以将这个页面及相关的资源都下载到本地或者本地的 Web 服务器,浏览器打开本地文件同样也可以发起呼叫。

(2)「server」指定 miniSIPServer 的地址。该 miniSIPServer 必须已经成功加载证书和密钥、并启动了 WSS 服务。miniSIPServer 默认总是采用 TCP 5062 端口启动 WSS 。

(3)「clr」发起呼叫的主叫用户号码。该号码必须是 miniSIPServer 的分机用户号码。

(4)「pwd」主叫用户用于鉴权的密码,即 miniSIPServer 分机用户的密码。miniSIPServer 用「号码+密码」对呼叫进行鉴权,只有鉴权通过的呼叫才允许接入,否则 miniSIPServer 会直接拒绝呼叫。

(5)「cld」呼叫的被叫号码,可以是本地分机号码,也可以是外呼号码。


语音流通过 DTLS-SRTP 传输,采用端对端协商和加密,miniSIPServer 无需对媒体进行额外配置。

miniSIPServer 仅需要配置证书和密钥启动 WSS 服务,接受浏览器 MCCP 呼叫消息。miniSIPServer 要求(1)证书和密钥保存在「应用数据目录」的「wrtcCert」子目录下;(2)文件必须是 PEM 格式;(3)证书保存为 server.crt 文件,密钥保存为server.key 文件。例如,在 Linux 系统中这两个文件应该如下所示:

$HOME/.minisipserver/wrtcCert/server.crt
$HOME/.minisipserver/wrtcCert/server.key

如果正常加载证书和密钥,miniSIPServer 将启动 WSS 服务并提示以下信息:

如果采用自签名证书,务必要注意在 Chrome、Firefox 等浏览器中允许加载自签名的证书。

Keep-alive

Keep-alive

在 SIP 通信领域,keep-alive (保活)有两种:设备的 keep-alive 与会话(session,dialog)的 keep-alive。

设备的 keep-alive 目前大家都有成熟统一的解决方案,并且符合 RFC3261 的要求,那就是采用 OPTIONS 操作进行检测,如果对端设备返回 200OK 则说明设备 keep-alive。终端采用 REGISTER 也可以检测设备 keep-alive。

各厂家一直都没有会话 keep-alive 的统一解决方案。RFC4028 规范虽然定义了 reINVITE 和 UPDATE 用于会话 keep-alive 检测,但是这两个操作用于会话检测显得太复杂了,会导致重新协商媒体,影响会话的通话质量。

目前各厂家的思路倒是基本一致:既然正常的 reINVITE 和 UPDATE 操作会导致新的媒体协商,那不携带 SDP 是不是就可以直接用于会话的 keep-alive?当然, reINVITE 是例外,「reINVITE without SDP」已经被用于 3PCC 流程,因此不可能再用于会话 keep-alive 操作。

我们根据历年与各厂家设备对接的经验,总结以下用于会话 keep-alive 的操作:

  • UPDATE without SDP
  • INFO without SDP
  • MESSAGE without SDP

最新版本 miniSIPServer 的默认处理方式:如果在会话过程中收到上述三种 SIP 消息,将进入会话 keep-alive 处理流程;如果会话存在,则返回 200OK 消息。

UPDATE 和 INFO 本身就只能在会话中传递,因此天然契合 keep-alive 的要求。我们推荐优先采用 INFO,RFC3261 明确定义了 INFO,各厂家设备一定会支持 INFO 操作。而 UPDATE 操作定义在补充协议中,部分厂家的设备未必会支持 UPDATE,更遑论 「UPDATE without SDP」。

MESSAGE 即可以在会话内传递,也可以在会话外发起,用于传递即时消息(instant message)。我们限定 「MESSAGE without SDP」只能在会话内传递,并保留给 keep-alive 流程处理。

改进「基于 TLS 的 SIP」

改进「基于 TLS 的 SIP」

以前的 miniSIPServer 版本如果想启动「SIP over TLS」,必须配置证书和密钥文件(包括自签名证书和密钥)。如果在配置目录中没有这些文件,miniSIPServer 默认不启动 SIP over TLS。

大部分客户部署「SIP over TLS」都采用自签名证书和密钥。Linux 系统自带 openssl 工具,很容易、也很方便创建这些文件,然而 windows 系统默认没有 openssl 工具,客户需要下载工具来创建证书和密钥,略显麻烦。

为了简化客户的工作量,我们优化了 miniSIPServer 启动「SIP over TLS」的一点步骤:

miniSIPServer 默认总是启动「SIP over TLS」。如果配置了证书和密钥文件,则以客户的证书和密钥加密 SIP 消息;如果没有配置证书和密钥文件,miniSIPServer 自动创建自签名证书和密钥加密 SIP。

因此,miniSIPServer 启动时,我们能看到 TLS 端口信息,这表明 miniSIPServer 启动了「SIP over TLS」:

安全的企业 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 (或者 DTLS-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 协议;同时也支持 RFC5763, 也就是支持 DTLS-SRTP——目前市面上有很多 SIP 终端设备并不支持 DTLS-SRTP,如果需要部署,需要仔细检查终端的能力。

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

MicroSIP 配置 SRTP
欢迎! Debian 13 (Trixie)!

欢迎! Debian 13 (Trixie)!

Debian 13 (Trixie) 昨天发布了。这个版本是最新的稳定版本,非常适合商业部署。我们是 Debian 系统的忠诚粉丝,第一时间在该系统上安装、测试了 miniSIPServer。所有的测试用例都通过了,结果很完美!

在 Debian 13 (Trixie) 系统上运行 miniSIPServer

您可以在 Trixie 系统上部署 miniSIPServer,构建企业通讯环境,这绝对是一个令人兴奋的选择!

miniSIPPhone 支持 SIP over TCP/TLS

miniSIPPhone 支持 SIP over TCP/TLS

是的,我们又升级 miniSIPPhone了!

miniSIPPhone V10.10 现在可以支持 SIP over TCP/TLS。在 SIP 账户的配置中新增了“传输”一项,用于指定采用哪种传输方式连接 SIP 服务器:

SIP 账户中“传输”项的配置

如果采用 SIP over TLS,那所有的 SIP 消息都是加密传输。如果企业通信系统中的设备(分机或者服务器)是部署在公共网络,那就非常有必要对通信内容进行加密保护。我们知道云 miniSIPServer 系统支持 SIP over TLS,而且云系统都部署在公共网络中,因此如果客户端同时部署 miniSIPPhone 的话,整个企业 VoIP 系统显然会更安全。

当然,miniSIPPhone 也可以与其他支持 SIP over TCP/TLS 的服务器(或者 PBX )一起工作,共同构建完整、安全的企业通信系统。

发送和接收即时消息(Instant messages)

发送和接收即时消息(Instant messages)

今天我们发布了最新版本的 miniSIPPhone(一款小巧的、适合企业通信的软电话),主要包含了两个新特性:(1)通信录,以及(2)即时消息。

miniSIPPhone 用一个新的窗体来创建、管理通信人列表:

miniSIPPhone 通信录

在通信录中,您可以选择一个目标用户,然后双击(或者按“C”键、或者点击“呼叫”按钮)发起呼叫。

如果希望发送即时消息,选择目标用户后按“M”键(或者点击“发消息”按钮),显示即时通信窗体发送消息:

miniSIPPhone 即时消息窗体(Windows系统)
miniSIPPhone 即时消息窗体(Linux系统)

每个用户对应一个独立的即时消息会话窗体。每个窗体包含三个区域:(1)消息显示区域。本区域显示会话中的所有即时消息,包括发送的消息和接收的消息。(2)输入区域。在该区域中可以输入消息的内容,然后按“Ctrl+Enter”键发送消息。(3)“发送”按钮,当然也是发送消息。

miniSIPPhone 使用 SIP-MESSAGE 操作发送和接收即时消息,目前仅支持纯文本消息,也就是不支持:图片、文件、语音以及视频等内容。

当然,miniSIPPhone依然能够运行在 Windows 和 Linux 系统(包括 AMD64 和 ARM64 架构)。实际上,上图中的两个软终端就运行在不同的系统上。

希望您能喜欢 miniSIPPhone!:-)

电话号码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 发起的呼叫。

miniSIPPhone 支持 Linux 系统(Debian、Ubuntu)

miniSIPPhone 支持 Linux 系统(Debian、Ubuntu)

miniSIPPhone 终于升级到 V10 版本,该版本最重要的特性就是支持 Linux 系统。当然,Linux 系统必须是 Debian 或者 Ubuntu 系列的发行版本。与 miniSIPServer 的要求一样,Debian 版本要求是 V10(Buster)及以上版本,Ubuntu 版本要求是 V18.04(Bionic Beaver)及以上版本。

同时支持 X86_64 以及 ARM64(AArch64)两种硬件架构。

现在在 Linux 系统运行 SIP 电话非常简单,请访问我们的网站下载最新的版本:

例如,您下载的版本是“msp_v10_amd64.deb”,采用以下命令安装:

sudo dpkg --install msp_v10_amd64.deb

接下来就可以点击图形界面快捷方式运行 miniSIPPhone:

如果想卸载 miniSIPPhone,则使用以下命令直接删除即可:

sudo apt remove minisipphone
会议室以及其他

会议室以及其他

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

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