此图例以及以下图例均来自于互联网资源关于其它信令支持方式和WebRTC核心概念，ICE/SDP, Offer/answer模式和主要应用场景等，笔者在下面的链接中已经进行了比较详细地分享说明。今天，我们重点对WebSocket 协议进行讨论。
完整SIP/SDP媒体协商概论-WebRTC/ICE概览
完整WebRTC架构ICE连接等技术详解及应用场景分析
很多用户可能对WebRTC和WebSocket的概念比较模糊。除了web相同以外，从简单命名我们就可以看出其基本差异，一个是RTC-实现实时通信，一个是socket-实现连接。实际上，它们两者之间存在很大不同，包括应用场景，传输方式， 技术实现目标都有着某些差别。网络有很多这方面的资料，读者可以进一步学习其差别。我们这里主要讨论的是基于WebRTC用户场景中，使用WebSocket协议实现的SIP子信令的支持，特别重点强调的是RFC7188-The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)，包括其IP语音方案背景说明和RFC7188规范详解。
1-背景说明
随着WebRTC的部署应用越来越多，无论是基于浏览器的终端方面还是IP语音通信的服务器端方面发布了很多的规范来支持WebRTC技术，并且重点强调了通过WebSocket实现对SIP协议的支持，例如，ETSI TS 124 371中规定的WIC (WebRTC IMS Client) 。很多业务场景中，比如WebRTC-SIP或者WebSocket gateway网关，SBC，服务器端（例如Asterisk，FreeSWITCH，Kamailio/OpenSIPS和其它商业解决方案）客户端（例如，JsSIP）等已经开始支持了WebSocket SIP子协议。
另外，很多的基于WebSocket的浏览器终端除了支持SIP协议以外，也支持了WebSocket，实现了RFC7188中规定的SIP WebRTC客户端（例如jsSIP）的功能定义。
SIP WebSocket Client: A SIP entity capable of opening outbound connections to WebSocket servers and communicating using the WebSocket SIP subprotocol as defined by this document. SIP WebSocket Server: A SIP entity capable of listening for inbound connections from WebSocket clients and communicating using the WebSocket SIP subprotocol as defined by this document.
比较常见的应用场景是SBC，呼叫中心或者IPPBX和WebRTC客户端的对接。WebRTC客户端（JsSIP）通过SIP通过WebSocket连接实现和SBC或者WebRTC网关设备进行通信，然后SBC通过SIP通过UDP，TCP或者TLS连接方式和对端SIP终端进行通信。
具体应用示例如下-WebRTC 客户端通过WebSocket实现SBC对接支持：
2-关于RFC7118 规范完整详解
2.1-关于RFC7118 介绍
WebSocket已经有具体的规范定义，RFC6455对其进行了详解说明。根据RFC6455的规范说明，WebSocket是基于TCP连接创建的连接协议，初始协议握手使用的是HTTP（RFC2616）协议，通过主要的方式可以实现WebSocket重用现存的HTTP架构。
随着互联网发展，很多浏览器兼容了更多的功能，同时也支持了更多的协议栈，W3C也要求支持了WebSocket栈，通过WebSocket API接口实现支持。通过这样的规范，个人PC端，智能手机也希望能够支持这些WebSocket API客户端应用。RFC7118是针对以上需求发布的规范。我们今天重点介绍的RFC7118就是一个这样的协议，RFC7118发布使得浏览器支持SIP网络成为可能。
实际上，RFC7118是RFC6455的一个子规范，它定义了WebSocket 客户端和服务器端传输SIP消息的机制，它是一个可靠性的，支持SIP消息体边界预留，针对SIP的传输协议，支持了DNA NAPTR服务值。另外，RFC7118定义了两个SIP实体(包括了SIP WebSocket 客户端和SIP WebSocket 服务器端)在部署WebSocket时的流程。基于SIP的WebSocket 客户端可以开启一个对服务器端的连接，基于SIP的WebSocket 服务器端可以监听一个连接。注意，媒体传输不在RFC7118讨论范围之内。
2.2-WebSocket Protocol
在介绍其它细节之前，我们首先介绍一下关于WebSocket协议（RFC6455）和其加密TLS支持协议。此协议定义了连接握手机制，WebSocket子协议，扩展协商，用来发送应用和控制数据的帧格式，掩码机制和关闭连接状态码等内容。
协议通信的连接首先需要处理连接握手。WebSocket协议握手连接是基于HTTP握手机制，使用Get method配合Upgrade请求来实现。客户端发送请求，服务器端接收请求，协商成功后，通过HTTP 101状态码进行回复响应。一旦握手完成后，这个连接就会从HTTP更新为WebSocket协议。握手协议设计目的是为了重用HTTP架构。在连接握手期间，客户端和服务器端都同意在应用层协议使用WebSocket协议来进行传输，并且在双方终端之间定义了消息交互的格式和语义。这样的处理机制可以支持一个自定义的协议或者一个标准的协议，具备了一定的灵活性和可扩展性。以下图例是客户端和服务器端更新切换协议的处理机制说明。
这里要注意，一旦HTTP 101 响应处理后，客户端和服务器端将会重用潜在的TCP来发送WebSocket消息，控制双方的帧格式。和HTTP不同的是，这里的HTTP连接是一个持久的连接，可以用来支持多个消息的交互。关于其握手处理方式，读者可进一步阅读RFC6455-4章节的Opening Handshake 了解更多详情，这里不再进行进一步讨论。
除了握手以后进行的数据交互机制以外，RFC6455中的WebSocket也定义了为了进行数据交互，在应用程序中使用的消息单元，因此它提供了一个所谓的message-boundary-preserving transport layer，我们称之为消息边界预留传输协议层。这些消息单元可以包含UTF-8文本数据或二进制数据和ping/pong帧数据，并且这些UTF-8文本数据或二进制数据可以进一步分解为多个WebSocket的UTF-8文本数据或二进制数据传输帧数据支持WebSocket处理需要。
2.3-The WebSocket SIP Subprotocol
通常情况下，我们这里讨论的WebSocket Subprotocol是基于WebSocket连接的应用层的协议。在RFC7188中我们特别针对的是WebSocket SIP 子协议，此协议通过WebSocket连接传输SIP请求和响应。在此子协议中，我们仍然需要从连接握手为切入点来进行讨论。在SIP WebSocket 客户端和服务器端协商中，双方WebSocket握手协商流程是在RFC6455-1.3章节进行定义的。在此规范中，我们使用的是SIP协议。因此，客户端在握手请求的头字段Sec-WebSocket-Protocol中必须包括“SIP”值，而且在服务器端的101回复响应中，其相应的Sec-WebSocket-Protocol要必须包含一个“SIP”值。在以下WebSocket 握手连接中，客户端发送了一个WebSocket SIP subprotocol，同样服务器端回复的响应中支持了这个请求：
GET / HTTP/1.1 Host: sip-ws.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://www.example.com Sec-WebSocket-Protocol: sip // 包含的SIP 头字段 Sec-WebSocket-Version: 13
从服务器端返回的握手响应中支持了WebSocket SIP subprotocol，表示服务器端接受了此WebSocket的握手：
HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: sip // 包含了SIP 头字段值
一旦双方在成功完成了此协商，WebSocket就创建好了。创建好了以WebSocket的连接以后，这个连接就可以用来发送SIP 请求和响应。这里一定要注意，此连接仅传输SIP请求和响应消息，此连接不支持非SIP请求响应消息的传输。关于SIP消息编码。传输完成后，当然接下来还要涉及对SIP消息的解码。前面我们已说明，WebSocket消息可以通过UTF-8文本帧格式或者二进制帧格式进行传输。比较巧合的是，SIP协议中的请求和响应中也支持文本和二进制的消息体传输。因此，SIP WebSocket客户端和SIP WebSocket服务器端双方必须接受文本帧格式和二进制帧格式数据。这里需要注意，如果在SIP消息中至少出现了一个非UTF-8格式标识字符（包括SIP头字段和消息体），那么整个消息一定要以一个WebSocket二进制消息再次发送。这里，因为JavaScript and the WebSocket API的属性，RFC7188规范推荐使用UTF-8编码对通过WebSocket连接传输的SIP消息进行处理。
2.4-SIP WebSocket Transport
根据RFC6455规范定义，我们知道WebSocket是一种可靠性协议。因为其继承关系，我们这里的SIP WebSocket 子协议也是一种可靠性协议，也是一种SIP可靠性传输协议。简言之，无论是SIP客户端和服务器端之间的事务，使用了WebSocket连接来传输的话，它们之间的可靠性传输必须按照RFC3261定义的流程和定时器来执行。
这里特别说明的是，每个SIP消息一定要通过单个WebSocket消息中传输，并且，一个WebSocket消息一定不能包含超过一个以上的SIP消息。因为WebSocket传输预留了消息体的边界设置，因此，当使用WebSocket传输SIP消息时，SIP消息中的Content-Length 头字段不是一个必要的字段。通过这样的方式可以简化在SIP客户端和服务器端的SIP消息解析流程。解析SIP消息时，无论是客户端还是服务器端无需通过Content-Length来创建消息边界范围。在解析SIP消息体时，有几个比较重要的SIP头字段需要说明。
首先说明的是Via传输参数。我们知道，Via头字段在SIP消息中发送传输协议的身份标识。在RFC7188中，这里定义使用的是“WS”值通过普通WbeSocket发送请求，通过加密的WebSocket连接“WSS”（secure WebSocket）发送加密的请求，按照RFC5246 TLS传输规范处理。具体消息语法格式如下：
transport =/ "WS" / "WSS"
另外一个比较重要的SIP头字段是SIP URI 传输参数。此规范定义了针对SIP URL使用的传输参数是“WS” 。具体的语法格式如下：
transport-param =/ "transport=" "ws"
还有一个比较重要的SIP头字段是 Via中的“received”。关于Via "received" 参数的处理需要加以特别的注意。在SIP协议第18章节中关于接收请求中，接收请求可以是域名或者IP地址。"received"参数中必须包含一个数据包接收的源地址。
当服务器传输通过任何传输收到一个请求时，它必须检查在顶部的 Via 头值中的“sent-by”参数。如果“sent-by”参数中的 host 主机部分包含一个 domain 名称 或者如果它包含一个 IP 地址，这个地址不同于数据包源地址，此服务器必须在 Via 头字段中添加一个“received”参数。这个参数必须包含一个从数据包收到的源地址。这样做的目的是帮助服务器端传输发送响应，因此，它必须源 IP 地址，这个地址是从请求方来的地址。
www.sip.org.cn
不幸的是，增加对"received"参数支持不能很好地兼容到WebSocket协议的设计框架中。前面我们已经说明，WebSocket连接握手重用了现存的HTTP架构设计。在现存架构中，SIP WebSocket 客户端和服务器端之间可能会有大量的未知的HTTP代理和TCP均衡负载服务器。如果服务器端把源地址写入到Via中的“received”头字段中，这些地址可能就是SIP实体的前端HTTP或者TCP中介的地址。这样会引起内部服务器地址或者敏感地址暴露给了客户端的问题。可能用户需要考虑一些折中的办法来对Via中的“received”进行处理。假设这样的一个场景中，SIP响应仅可以通过现存的WebSocket连接发送，这样的话，就不会有太多的Via中的“received”参数使用。因此，为了避免SIP WebSocket内部服务器的敏感地址暴露给客户端，RFC7188更新了RFC3216中18.2.1章节的描述。具体描述更新为以下内容：
当一个SIP WebSocket服务器端收到了一个请求时，它可以决定不在TOP Via参数中添加一个“received”参数。因此，无论Via头中的"sent-by"是否包含域名，SIP WebSocket客户端必须接受在Top Via中无这样的参数的响应。
SIP实体的定位服务（Locating a SIP Server）是非常重要的。RFC3261有对SIP服务器定位的定义。在本规范中，针对SIP WebSocket服务器端定义了自己的方式，此规范支持NAPTR服务值"SIP+D2W"来实现普通的SIP WebSocket服务器端的定位服务，加密服务提供“SIPS+D2W”实现。这里要提醒用户，在此规范发布时，DNS NAPTR/Service Record (SRV) queries仍然不能很好地支持WebSocket 客户端（包括一些JavaScript 引擎和页面浏览器）。在DNS NAPTR/Service Record缺省或者声明端口场景中，对于SIP URL来说仍然使用默认端口，“WS”传输端口是默认的80端口，默认加密端口是443端口。
2.5-连接存活机制
我们知道，如果要保证一个socket一直处于连接状态，双方都要不断通过发送存活消息来验证其状态和心跳。SIP WebSocket 客户端和服务器端也不例外。如果它们之间要一直保持一个开放状态的话，它们需要周期性地发送一个“Ping或者Pong” 帧数据（乒乓球来回处理）。这个处理机制在RFC6455-5.5.2章节中有说明。
当前可能存在的问题是，对于某些运行于浏览器的应用，它们的WebSocket API不支持类似的处理机制，对客户端或者服务器端周期性地发送Ping消息或者回复Pong消息。这些应用完全取决于浏览器支持本身或者浏览器设置。目前，比较主流的浏览器对存活支持还是比较友好的。关于SIP连接的存活机制的讨论，用户可以参考其它两个规范RFC5626-3.5.1或者RFC6223规范来进一步学习存活机制的状态设置。
2.6-关于WebSocket客户端和服务器端之间的认证机制
认证是现代网络环境安全运行的必要条件。因为WebSocket应用应用于浏览器端，客户端需要和服务器端执行双向交互实现文本，语音和视频的交互。而且很多时候，服务器端需要对特定客户端执行特别路由处理，因此，服务器端对客户端的身份认证是非常必要的。在本规范RFC7118中利用了其它规范进行身份认证，其相关协议包括RFC6455，RFC6265，RFC2617和RFC3261。需要注意的是，在WebSocket 协议（RFC6455）中没有具体定义认证机制，但是其协议公布了一个连接握手时的WebSocket Client Authentication说明。具体来说，RFC6455的关于WebSocket 客户端认证是这样描述的，在握手连接期间，RFC6455不提供关于客户端认证的具体机制，WebSocket 可以使用对一般HTTP服务器支持的任何客户端的认证机制来进行验证，例如，cookies, HTTP authentication或者TLS authentication。为了更好地实现客户端和服务器端认证兼容性支持，在WebSocket 认证层面，RFC7188规范发布了强制支持和可选的关于SIP WebSocket 客户端和服务器端的兼容性列表：
当运行在浏览器环境时，SIP WebSocket 客户端必须准备添加一个会话cookie, 并且前面已经从页面服务器获取了一个会话cookie，此页面服务器URL域名匹配WebSocket域名。具体规范参考RFC6265。
当执行WebSocket 握手时，SIP WebSocket 客户端必须准备挑战由SIP WebSocket服务器返回的带HTTP 401状态码响应。具体规范参考RFC2617。
SIP WebSocket客户端可以使用TLS客户端认证作为可选认证机制。
当cookies出现在WebSocket握手请求时，SIP WebSocket服务器端必须准备读取会话cookies，并且使用这些cookies值来决定是否WebSocket 连接已经被HTTP 客户端初始化，作为SIP WebSocket服务器端正在和同样域名的网站进行协商处理。
SIP WebSocket服务器应该可以拒绝一个带HTTP 401状态码的WebSocket握手请求。这个HTTP状态码是由一个HTTP协议定义的Basic/Digest challenge提供。
2.7-SIP-WSS场景示例
在SIP应用中，绝大部分的使用场景涉及了SIP注册和SIP呼叫主要流程。在RFC7118规范在列出了关于SIP-WSS注册和SIP INVITE呼叫流程。首先，我们介绍如何通过SIP WSS对SIP WebSocket 服务器端进行注册的示例。以下图例说明了Alice客户端通过SIP WSS对代理服务器进行注册，注册大概需要4个流程来完成，它们分别包括：连接握手成功，返回101 状态码，切换为SIP注册，执行SIP注册，返回成功注册响应码。
根据以上图例，我们具体说明其步骤。首先，Alice使用浏览器加载页面，获取到带JavaScript，其代码应用支持了本规范规定的WebSocket SIP子协议。脚本代码作为一个SIP WebSocket客户端尝试和SIP WebSocket服务器端(proxy.example.com)创建连接握手。基于创建的连接，Alice发送一个SIP注册请求，请求中包含了Outbound和GRUU支持。因为，浏览器中的脚本代码无法决定来自于WebSocket连接的本地地址，因此使用了一个任意的".invalid" 域名来支持Via头字段中的"sent-by"参数和Contact头字段中的URL的主机端口。 具体流程如下：第一步，发送GET，开始WS握手：
F1 HTTP GET (WS handshake) Alice -> proxy.example.com (TLS) GET / HTTP/1.1 Host: proxy.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: https://www.example.com Sec-WebSocket-Protocol: sip Sec-WebSocket-Version: 13
第二步：服务器端发送101状态码，进行协议切换
F2 101 Switching Protocols proxy.example.com -> Alice (TLS) HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: sip
第三步，通过WSS传输进行SIP注册：
F3 REGISTER Alice -> proxy.example.com (transport WSS) REGISTER sip:proxy.example.com SIP/2.0 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf From: sip:alice@example.com;tag=65bnmj.34asd To: sip:alice@example.com Call-ID: aiuy7k9njasd CSeq: 1 REGISTER Max-Forwards: 70 Supported: path, outbound, gruu Contact:;reg-id=1 ;+sip.instance=""
第四步，服务器返回完成SIP注册消息：
F4 200 OK proxy.example.com -> Alice (transport WSS) SIP/2.0 200 OK Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf From: sip:alice@example.com;tag=65bnmj.34asd To: sip:alice@example.com;tag=12isjljn8 Call-ID: aiuy7k9njasd CSeq: 1 REGISTER Supported: outbound, gruu Contact:;reg-id=1 ;+sip.instance="" ;pub-gruu="sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1" ;temp-gruu="sip:87ash54=3dd.98a@example.com;gr" ;expires=3600
除了SIP-WSS注册流程以外，RFC7118规范列出了一个通过SIP INVITE进行语音呼叫的示例列出。具体流程图示例如下，呼叫流程大概经过了11个步骤。
根据以上流程图，首先Alice多Bob的AOR地址进行了呼叫。SIP WebSocket服务器端proxy.example.com作为一个SIP代理服务器，路由此呼叫到相应的Bob的contact地址。代理服务器和Bob之间的SIP呼叫通过UDP传输完成。Bob接听了呼叫，然后挂机。第一步，Alice通过WSS呼叫：
F1 INVITE Alice -> proxy.example.com (transport WSS) // WSS INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com Call-ID: asidkj3ss CSeq: 1 INVITE Max-Forwards: 70 Supported: path, outbound, gruu Route:Contact:Content-Type: application/sdp
第二步，代理服务器返回100 trying。
F2 100 Trying proxy.example.com -> Alice (transport WSS) SIP/2.0 100 Trying Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com Call-ID: asidkj3ss CSeq: 1 INVITE
第三步，代理服务器呼叫Bob，通过UDP传输。
F3 INVITE proxy.example.com -> Bob (transport UDP) INVITE sip:bob@203.0.113.22:5060 SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Record-Route:,From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com Call-ID: asidkj3ss CSeq: 1 INVITE Max-Forwards: 69 Supported: path, outbound, gruu Contact:Content-Type: application/sdp
第四步, Bob返回响应，准备接收呼叫。
F4 200 OK Bob -> proxy.example.com (transport UDP) SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c ;received=192.0.2.10 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Record-Route:,From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 INVITE Contact:Content-Type: application/sdp
第五步，代理服务器对Alice 返回 200 OK：
F5 200 OK proxy.example.com -> Alice (transport WSS) SIP/2.0 200 OK Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Record-Route:,From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 INVITE Contact:Content-Type: application/sdp
第六步，确认 200 OK:
F6 ACK Alice -> proxy.example.com (transport WSS) ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 Route:,, From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 ACK Max-Forwards: 70
第七步，代理服务器确认 200 OK:
F7 ACK proxy.example.com -> Bob (transport UDP) ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhwpoc80zzx Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 ACK Max-Forwards: 69
双方开始RTP语音流，正式通话。然后Bob首先挂机，发送BYE消息到代理服务器，代理服务器再发送BYE消息到Alice SIP WebSocket 客户端。最后，Alice对代理服务器发送BYE消息的200 OK, 然后代理服务器对Bob发送BYE消息的200 OK。
F8 BYE Bob -> proxy.example.com (transport UDP) BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 Route:,From: sip:bob@example.com;tag=bmqkjhsd To: sip:alice@example.com;tag=asdyka899 Call-ID: asidkj3ss CSeq: 1201 BYE Max-Forwards: 70
代理服务器对Alice发送BYE消息，后续流程忽略。
F9 BYE proxy.example.com -> Alice (transport WSS) BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 From: sip:bob@example.com;tag=bmqkjhsd To: sip:alice@example.com;tag=asdyka899 Call-ID: asidkj3ss CSeq: 1201 BYE Max-Forwards: 69
在RFC7188规范中还规定了其它的一些安全考虑和语法规范，例如关于加密WebSocket连接使用，关于SIPS的使用，SIP注册的进一步说明，部署指南，用户认证场景等章节。这些章节相对不是非常重要的内容，笔者这里不再讨论。
3-总结
很多程度上，WebRTC的技术发展依赖于浏览器的技术发展。通过浏览器实现和电脑设备的通信是互联网应用的一个大的飞跃，它能够融合更多的语音，视频和其它数据交互。在企业通信方面，WebRTC利用WebSocket传输实现SIP语音通信让企业通信能力上了一个新的台阶。RFC7188规范对SIP通信结合WebSocket传输进行了完整的规定，用户通过SIP websocket 客户端和服务器端实现浏览器和其它应用的对接。笔者首先介绍了WebRTC以及WebSocket的应用场景，包括IMS的规范要求，另外，详细介绍了关于RFC7188的核心内容，包括连接握手，存活处理，用户认证和SIP传输以及语法定义和注册呼叫示例。笔者希望用户在部署SIP WebSocket客户端和服务器端的过程中能够充分考虑到其业务的局限性，另外可以充分利用SIP WebSocket 客户端和服务器端的灵活部署能力来服务更强大的业务场景。
参考资料：
https://libwebsockets.org/
https://www.rfc-editor.org/rfc/rfc7118.html
https://www.rfc-editor.org/rfc/rfc6455.html
www.asterisk.org.cn
www.asterisk.org
www.dinstar.cn
https://jssip.net/
www.sip.org.cn
https://github.com/resiprocate/resiprocate/wiki/WebRTC-and-SIP-Over-WebSockets
https://github.com/SIPp/sipp/issues/124https://www.etsi.org/deliver/etsi_ts/124300_124399/124371/15.02.00_60/ts_124371v150200p.pdf
https://arxiv.org/abs/1601.00184
