企业已经部署SIP服务器或IP PBX，如果希望员工直接通过浏览器拨打和接听电话，可以使用WebRTC软电话作为新的通信终端。用户打开网页后，通过企业分机账号建立通信连接，在获得麦克风使用权限的情况下，即可使用网页界面进行语音通话，不必另外安装传统桌面软电话。
不过，浏览器软电话并不能直接按照普通IP话机的接入方式连接所有SIP服务器。传统SIP终端主要通过UDP、TCP或TLS交换呼叫信令，而基于浏览器的SIP客户端通常通过WebSocket传递SIP消息，语音则使用WebRTC媒体机制传输。因此，实际接入需要分别解决SIP信令连接、分机认证和媒体互通三个问题。
浏览器与SIP服务器的接入条件
WebRTC提供浏览器实时采集和传输音视频的能力，但不规定必须使用SIP建立呼叫。要让网页电话成为企业电话系统中的一个分机，通常需要结合SIP.js、JsSIP等客户端库，在浏览器中实现SIP注册和呼叫控制，再使用WebRTC完成实时媒体通信。
与普通IP话机相比，浏览器无法直接通过网页JavaScript向任意SIP UDP端口发送消息。根据RFC 7118，SIP消息可以通过WebSocket传输，生产环境通常使用WSS建立加密信令连接。
因此，部署之前需要确认以下条件：
- SIP服务器或前置接入设备支持SIP over WebSocket，能够接收浏览器发送的SIP消息。
- 服务器提供可访问的WSS地址，并配置浏览器信任的TLS证书。
- 分机账号具有有效的认证信息、号码配置和呼叫权限。
- 通信平台具备WebRTC媒体接入能力，或者可以通过媒体网关适配ICE、DTLS-SRTP及相关音频编码。
- 终端与媒体服务之间具有可用的网络路径，必要时部署STUN、TURN或媒体中继。
其中，WSS主要负责传递REGISTER、INVITE、BYE等SIP信令。浏览器的实时语音并不依靠WSS承载，而是通过独立的媒体连接进行传输。
例如，某企业SIP服务器目前只提供UDP 5060端口，普通IP电话可以正常注册，但浏览器不能直接把该地址作为WebSocket接口。需要由现有服务器启用相应WebSocket信令服务，或者增加具备SIP over WebSocket能力的接入设备。
直接接入与网关适配
WebRTC软电话通常采用服务器直接接入或网关适配两种方式。两者都可以使用企业现有的SIP号码体系，但对服务器能力和网络结构的要求不同。
服务器直接支持WebRTC
如果现有SIP服务器同时支持SIP over WSS和WebRTC媒体协商，网页软电话可以通过服务器提供的WebSocket接口注册为SIP分机，再利用现有呼叫路由与其他终端通信。
FreeSWITCH便是一种可以采用这种方式部署的软件平台。其mod_sofia模块通过Sofia SIP Profile提供SIP接入能力，可以配置ws-binding或wss-binding，使浏览器中的SIP客户端通过WebSocket发送SIP消息。
在完成必要的媒体配置后，FreeSWITCH还可以处理WebRTC终端的ICE和DTLS-SRTP协商，并与传统SIP终端建立相应的语音连接。
需要特别区分，FreeSWITCH还提供mod_verto模块，用于接入采用Verto信令的WebRTC客户端。Verto通过WebSocket传输自身的信令消息，并不是将普通SIP REGISTER直接封装到WebSocket中。
如果网页端使用SIP.js或JsSIP等标准SIP客户端库，通常应选择mod_sofia提供的SIP over WSS方式。如果使用的是Verto客户端，则需要按照mod_verto的机制配置。两种方式都可能使用WebRTC传输媒体，但信令接口和客户端实现不同，不能混用。
通过网关接入传统SIP服务器
如果现有IP PBX只支持普通SIP信令和RTP媒体，可以通过具备相应功能的SBC、WebRTC-SIP网关或媒体接入服务进行适配。
浏览器侧通过WSS连接接入网关，网关根据内部路由配置将SIP信令转发或转换至原有服务器。语音侧则由媒体服务处理WebRTC与传统SIP终端之间的媒体差异。
例如，浏览器使用DTLS-SRTP传输加密语音，而旧IP话机只支持普通RTP。如果两者无法直接协商兼容的安全媒体连接，就需要由具备相应能力的服务器或网关终止两侧媒体连接，完成安全媒体转换。双方音频编码不同且没有共同编码时，还可能涉及转码。
普通SIP代理或WebSocket反向代理并不必然具有媒体转换能力，因此不能仅凭设备支持WSS，就认定它能够完成WebRTC与传统RTP话机的完整互通。
| 比较项目 | 直接接入 | 网关适配 |
|---|---|---|
| 适用条件 | SIP服务器支持WebRTC信令及媒体 | 原有SIP平台缺少相关能力 |
| 信令连接 | 浏览器通过WSS连接服务器 | 浏览器通过WSS连接网关 |
| 号码管理 | 沿用现有分机及路由体系 | 通过网关与既有号码体系对接 |
| 媒体处理 | 由兼容的媒体服务器或终端处理 | 通过媒体网关完成必要的适配 |
| 主要检查内容 | WSS、ICE、DTLS-SRTP及编码 | 网关兼容性、媒体转换及路由 |
对于已经稳定运行的企业电话平台，应先核查其实际WebRTC支持能力，再决定是否增加网关。若现有服务器本身已经具备相关功能，通常没有必要为了浏览器接入而额外增加一层协议转换。
从分机注册到语音通话
明确接入方式后，需要配置网页软电话的SIP身份、信令地址和媒体连接参数。以分机8001接入企业SIP服务器为例，接入配置通常包括以下内容。
网页软电话需要配置哪些参数
| 配置项目 | 示例或用途 |
|---|---|
| 网页访问地址 | https://phone.example.com |
| WSS服务器地址 | wss://sip.example.com:7443 |
| SIP用户地址 | sip:8001@example.com |
| 分机号码 | 8001 |
| 认证用户名 | 按服务器账号配置填写 |
| 认证密码 | 由通信平台分配并安全管理 |
| SIP域名 | example.com |
| ICE服务器 | 根据网络情况配置STUN或TURN |
| 音频编码 | Opus、G.711等双方支持的编码 |
| 拨号规则 | 由现有SIP服务器的号码路由决定 |
上述域名、账号和WSS端口仅为配置示例，不代表科能融合或FreeSWITCH的默认生产环境参数。不同SIP服务器可能使用不同的WebSocket监听端口、URL路径和注册域名，实际配置应与服务端保持一致。
还需要注意，SIP用户地址和认证用户名不一定相同。例如，用户地址用于标识分机身份，认证用户名则用于服务器验证。客户端需要按照服务器所采用的账号体系分别配置，而不能默认两者始终一致。
WSS连接与SIP注册
用户通过HTTPS访问网页软电话后，客户端首先建立到SIP服务器的WSS连接。连接成功意味着浏览器和服务器之间具备SIP信令传输通道，但分机此时不一定已经完成注册。
在典型SIP注册过程中，客户端发送REGISTER请求，服务器按照账号策略完成身份认证。采用SIP摘要认证时，可能出现首次REGISTER、401认证挑战、再次REGISTER和200 OK等交互。
注册成功后，服务器维护该分机的有效注册信息，使其他终端能够按照号码路由向浏览器发起呼叫。对于需要长期在线的网页客户端，还应根据注册有效期和连接状态执行必要的刷新与重新注册。
建立呼叫与媒体连接
假设浏览器分机8001拨打普通IP话机8002，客户端通过WSS发送SIP INVITE请求，服务器根据号码规则找到8002并发起呼叫。
双方通过SDP交换媒体参数，其中包括音频编码、媒体地址及WebRTC所需的相关属性。在媒体连接建立过程中，浏览器通过ICE收集候选地址并进行连通性检查，再通过DTLS协商SRTP媒体密钥。
如果8002是传统SIP话机，服务器或网关还需要根据双方能力建立兼容的媒体路径。通话接通后，浏览器通过已建立的媒体连接发送麦克风音频并接收远端语音。
典型过程可以概括为：
- 浏览器加载网页软电话并建立WSS信令连接。
- 客户端通过REGISTER完成SIP分机注册。
- 用户拨号，客户端发送INVITE，服务器执行号码路由。
- 双方通过SDP协商媒体参数，并完成相应ICE连接检查。
- WebRTC媒体端点建立DTLS-SRTP连接，开始双向语音传输。
- 通话结束时，通过BYE等信令释放会话资源。
以上是便于理解的逻辑顺序，实际ICE候选收集与信令交换可能交错进行。服务器负责处理SIP注册和呼叫路由，并不意味着所有实时媒体都必须经过注册服务器本身。
媒体互通中的网络与编码问题
在实际部署中，WebRTC软电话已经注册成功却无法通话，往往不是账号问题，而是网络或媒体参数没有匹配。SIP信令可以正常到达服务器，并不代表浏览器和媒体服务之间已经建立可用的音频连接。
ICE、STUN与TURN
浏览器可能位于办公局域网、家庭网络或移动网络中，SIP服务器与媒体网关又可能部署在不同网段。双方之间存在NAT或防火墙时，需要解决实际媒体地址的可达性问题。
ICE通过收集候选地址并进行连接检查，为媒体通信选择可用路径。STUN可以帮助终端了解自身经过NAT后的网络映射信息，TURN则可以在直连受限时提供媒体中继。
STUN和TURN并不负责SIP账号认证或电话号码路由，它们服务于媒体网络连通性。
对于浏览器与媒体服务器位于同一受控网络的情况，可能不需要通过TURN转发音频；如果双方位于不同公网、存在复杂NAT或受到严格防火墙限制，则可能需要TURN或其他媒体中继。
因此，部署时应分别检查WSS信令访问和媒体连接所需的网络策略，不能仅因浏览器能够连接WSS服务器就判断语音链路正常。
媒体加密与音频编码
WebRTC浏览器使用DTLS-SRTP建立安全媒体通信。DTLS用于协商媒体加密密钥，SRTP负责保护实际传输的音视频数据。它与WSS信令连接采用不同的安全机制。
如果既有SIP终端采用普通RTP，媒体服务器需要在符合安全策略的条件下处理WebRTC加密媒体与传统媒体之间的转换。这里可能涉及两侧媒体会话分别建立，但不一定需要改变音频编码。
常见的WebRTC音频编码包括Opus和G.711。普通SIP话机可能支持G.711、G.729或其他编码。双方具有共同编码时，可以减少不必要的转码；没有兼容编码时，则需要媒体服务器具备相应的转换能力。
对于语音质量要求较高的企业电话应用，还应关注丢包、网络抖动、音频缓冲、回声消除及实际端到端通话效果。仅凭媒体连接建立成功，不能判断最终语音质量符合要求。
网页软电话的实际部署要求
WebRTC软电话除了需要通信平台支持，还会受到浏览器安全机制、设备权限和网页运行状态的影响。这些条件在传统IP话机中通常由终端固件处理，但在网页应用中需要单独考虑。
HTTPS、麦克风与音频播放
浏览器通过getUserMedia接口访问麦克风时，通常要求网页运行在安全上下文中，例如有效的HTTPS环境，并获得用户授权。开发阶段的localhost存在特定例外，但正式部署不应依赖普通HTTP页面访问麦克风。
麦克风授权成功之后，还需要检查远端音频能否正常播放。浏览器可能根据自动播放策略限制未经用户交互就发声的媒体，尤其是在网页刚打开、没有进行过点击操作或标签页处于后台时。
因此，接入测试不能只确认本地麦克风采集正常，还需要检查：
- 远端音频流是否成功绑定到网页播放器。
- 浏览器是否允许音频播放，必要时是否需要用户点击接听或播放按钮。
- 网页播放器是否被静音，音量是否正常。
- 系统默认输出设备是否正确，例如扬声器、耳机或USB话务耳麦。
- 浏览器和操作系统是否限制了当前网页的音频输出。
如果SIP会话已经建立、ICE和DTLS状态也正常，但用户仍听不到声音，就不能只检查服务器RTP端口，还需要排查浏览器的播放状态和实际输出设备。
账号安全与分机权限
浏览器分机应遵循企业已有的号码管理和呼叫权限。员工可以使用分机号码进行内线互拨，外线呼出则应按照服务器配置的拨号规则、号码权限和线路策略处理。
SIP认证密码不宜直接写入公开网页源代码，也不应让不同用户共用不受控制的长期凭据。对于企业内部应用，可以通过登录验证及受控的账号配置方式管理分机身份，必要时结合服务器支持的认证机制进行权限控制。
如果网页应用需要对接CRM、工单或其他业务系统，还应区分业务系统登录身份与SIP通信身份，避免将浏览器页面的登录成功直接视为已经获得全部电话呼叫权限。
网页关闭与断线重连
传统IP话机通常保持长期注册状态，而网页软电话的运行依赖浏览器标签页和应用生命周期。用户关闭网页、电脑休眠、网络切换或WebSocket连接中断后，软电话可能失去呼入能力。
客户端应能够识别WSS断开和SIP注册失效，在网络恢复后重新建立信令连接，并根据实际状态重新注册分机。
需要注意，重新注册成功不代表断线前的通话能够自动恢复。已经建立的媒体会话可能因网络变化或页面关闭而终止，需要重新呼叫。对于确实要求持续在线的值班或接警岗位，应评估固定IP话机、专用桌面客户端等终端方式，而不是默认普通浏览器网页具备同等后台运行能力。
此外，如果网页软电话需要访问IVR语音菜单，还应测试DTMF按键传输。WebRTC浏览器通常通过协商的RTP telephone-event等机制发送电话按键信号，接入网关或SIP平台需要正确处理，不应把网页界面的按键显示与远端IVR真正收到按键信号混为一谈。
接入测试与常见故障
WebRTC软电话完成配置后，可以先通过一台浏览器终端与普通SIP话机进行测试。确认内线双向通信正常，再逐步验证跨网呼叫、外线权限、转接、DTMF及其他业务功能。
如果遇到故障，应按浏览器环境、WSS连接、SIP注册、呼叫建立和媒体传输逐层定位。
| 故障现象 | 重点检查内容 |
|---|---|
| 网页无法连接SIP服务器 | WSS地址、监听端口、TLS证书、反向代理和防火墙 |
| WSS连接正常但注册失败 | 账号、认证用户名、密码、SIP域名及REGISTER响应 |
| 浏览器无法使用麦克风 | HTTPS、麦克风授权、设备占用及系统权限 |
| 能够注册但呼叫失败 | INVITE响应、号码路由、呼叫权限及SDP协商 |
| 通话建立但双方无声 | ICE连接状态、DTLS协商、网络端口及媒体路由 |
| 对方能听到自己，自己听不到对方 | 远端媒体接收、音频自动播放、播放器及输出设备 |
| 只有单向语音 | NAT、防火墙、音频轨道、媒体转发和编码兼容性 |
| IVR按键无反应 | DTMF发送方式、telephone-event协商及网关转换 |
| 网络恢复后仍无法接听 | WSS重连、SIP重新注册、旧注册状态及呼叫路由 |
实际联调建议按照以下顺序进行：
- 访问HTTPS网页，确认浏览器能够获得麦克风权限，并正常选择音频设备。
- 建立WSS连接，检查服务器证书和WebSocket连接状态。
- 发送REGISTER请求，确认服务器返回注册成功响应。
- 测试浏览器分机呼出至普通SIP话机，以及普通SIP话机反向呼入。
- 检查ICE连接、DTLS状态和双向音频，确认双方都能正常听到声音。
- 分别在办公局域网及项目允许的外部网络中测试媒体连通性。
- 验证DTMF按键、呼叫保持、转接和其他实际需要的电话功能。
- 模拟网页刷新、网络中断和重新连接，检查分机能否恢复注册与后续呼入。
验收时，应分别记录WSS连接结果、SIP注册状态、呼叫建立结果、双向媒体情况及实际业务功能。对于媒体故障，可以结合浏览器的WebRTC诊断信息查看ICE连接状态、候选地址及媒体收发统计；对于信令异常，则应结合客户端和服务器的SIP日志定位。
需要区分注册成功、呼叫成功和通话质量合格三个结果。客户端显示在线，并不能代替双向语音测试；SIP会话建立成功，也不能证明远端音频播放、DTMF按键或跨网通话均已正常。
对于已经部署企业电话系统的单位，可以先核查现有SIP服务器是否支持SIP over WSS和WebRTC媒体接入。如果缺少相应能力，再评估是否通过媒体接入网关完成互通。有关网关的协议转换方式，也可参考WebRTC到SIP网关的相关介绍。具体功能需要结合通信平台的软件版本、媒体配置及网络条件确认。
WebRTC软电话接入SIP服务器，需要同时完成浏览器信令连接、SIP身份认证、号码路由与媒体互通。WSS解决浏览器如何传递SIP消息，ICE和DTLS-SRTP则关系到语音能否在实际网络中安全传输。将服务器接口、分机配置和浏览器运行条件分别验证，才能在保留现有企业电话系统的基础上，稳定增加网页通信终端。
