附图对本发明作进一步详细描述。
[0045]WebSocket的选项SIP在先前部分已经被讨论。如果目的在于提供API以开放给网页开发者，则SIP对网络用户不是最好的选择。
[0046]HTTP的REST已经在互联网的网页服务器上被广泛部署。电信的REST架构风格由 W3C TAG (Technical Architecture Group,技术架构组)与 HTTP/1.1 同时开发。基于RESTjOMA已经以RESTful网络API的形式定义了很多技术规范。所有OMA出版的REST API都是基于HTTP的，因为REST最初旨在典型的网页服务，浏览器/客户端2发起请求至服务器I ;服务器I处理请求，并返回合适的响应。
[0047]采用HTTP的REST，不得不使用长轮询，因为只有浏览器/客户端2发送请求，而服务器I不会。服务器I所发送给浏览器/客户端2的任何东西都不得不在对该浏览器/客户端2先前发送的请求的响应内。为了能使服务器I当其需要时能够发送任何东西(例如，浏览器/客户端2正在等待一些事件来继续处理服务，当这些事件发生时，服务器需要通知浏览器/客户端2)，浏览器/客户端2周期地发送长轮询请求，这样，从服务器I的角度，当需要往回发送东西时，有一个固定的HTTP请求可以由其使用。
[0048]这已经广为人知，并在网页服务中被广泛地接受。然而，对需要更实时的处理的电信服务来讲，延迟变得非常重要。并且，由于长轮询及建立和释放多个HTTP连接所引起的带宽消耗，也使得HTTP的REST很昂贵。
[0049]延迟的另一个重要原因是HTTP连接本身。
[0050]HTTP是基于TCP的。每次HTTP连接需要被建立，首先，TCP连接需要被建立，TCP具有众所周知的三次握手，其引起额外的延迟。公平的讲，HTTP本身就不适合实时通信，其使得HTTP的REST对实时通信来讲不是一个好的方法。
[0051]Websocket 的单向 REST 由 HTTP 的 REST 进化而来。其用 Websocket 取代了 HTTP传输。因此，仅有一个Websocket连接被建立，其被所有应用消息交换所重复使用。但是其继承了长轮询，即，浏览器/客户端2发送请求，服务器I仅发送响应，这样，必须总是为服务器I准备好有固定的请求，以使服务器I能够携带事件至浏览器/客户端2，这是为什么其被称为单向REST。因此，Websocket的单向REST仍旧具有由长轮询引起延迟及在带宽方面的费用问题。其是一个合并的解决方案，但其不具有由WebSocket-全双工实时连接所提供的优势。
[0052]SwaggerSocket是其中一个现有的Websocket的单向REST解决方案，由HTTP的REST进化而来。主要的改变是将HTTP替换为WebSocket，允许多个同步单向REST处理。然而，其不能充分利用WebSocket的全双工特性，仍旧工作在单向模式，不能解决由长轮询引起的如上所述的问题。
[0053]还有一个正在进行的标准变更请求，提出了一种通知信道的专用WebSocket连接，采用该连接，服务器I可以发送通知到没有使用长轮询的客户端。
[0054]有人可能会质疑如果我们将SwaggerSocket和专用Websocket连接相结合来进行通知，那还需要在此提出的WebSocket的双向REST么。实际上他们之间有一个关键的区另O。将SwaggerSocket和专用WebSocket连接相结合来进行通知,意味着维持两个分开的WebSocket连接(一个为了 SwaggerSocket,另一个为了通知信道),而WebSocket的双向REST提出了为双向通信使用相同的WebSocket连接。维持两个socket的劣势是明显的:
[0055]I) 一个socket相比两个socket:理论上，如果使用两个socket,系统容量可能下降一半。因此，WebSocket的双向REST给出两倍的容量。
[0056]2)两个socket可能具有他们自己的延迟特性，引起他们之间的时间/同步问题。例如，在由服务器I发送实际的通知之后，用户拨打新的电话给相同的呼入者，该呼入电话的延迟通知可能迟到，但是客户端只在电话被拨打之后收到该延迟通知(由于两个socket的异步性)。
[0057]实时系统需要实时的通信信道。将SwaggerSocket和专用WebSocket连接相结合来进行通知，可以为传统的网页APP进行工作，这些网页APP大部分实质上不是实时的，但是最近的WebRTC APP和HTML5 APP的新品种(游戏、文件编辑工具如google docs)需要更快地实时响应。
[0058]在WebRTC客户端复制传统SIP客户端的功能可能存在一个需要考虑的问题，那就是我们选择的信令协议是否有利于该复制的实现。基于WebSocket的SIP的确可以使该复制变得简单，但是如我们先前提到的，当API将要开放给网页开发者时，由于网页开发者一般不具备通信信令SIP的完备知识基础，因此其并不合适。并且，为了使用SIP作为WebRTC的信令接口协议，浏览器/客户端不得不加载重量级的JS库，以对网页开发者隐藏SIP处理过程。而网页用户则更倾向于采用轻量级的、简单的控制信令，因此，WebSocket的SIP并不是应用信令的理想解决方案。如果选择基于REST的方法，复制传统SIP客户端的功能对所有基于REST的方法的重量级/轻量级程度是相同的，而并不是双向REST所特有的问题。每个现有的SIP流程都需要相对应的REST版本，不同的基于REST的方法之间的区别在于消息(如，JSON)细节。
[0059]以下示出一些呼叫流程。呼叫流程中的标记不是标准的REST，但仅语义地解释了在浏览器/客户端2和服务器I之间被通信了什么。
[0060]图1示出现有技术的一种浏览器/客户端发起呼叫的示意图。
[0061]在图1所示该例中，由于在被叫方应答这个事件发生的时候没有可用的长轮询请求，在被叫方应答之后，事件(被叫方已应答)不能被及时通知至浏览器/客户端2。浏览器/客户端2通过下一个长轮询请求的响应，被通知被叫方应答事件，这样引起了延迟。
[0062]延迟取决于两个长轮询请求间的时间间隔，S卩，在得到上一个长轮询请求的响应之后，浏览器/客户端等待多久来发送另一个长轮询请求。延迟可能和在两个长轮询请求间的整个时间间隔一样长。不同的浏览器/客户端2可能选择不同的值。当以秒来计时，实时通信的延迟将变得巨大。
[0063]对该特殊的情形，终端用户(被叫方)在其应答后与呼叫方谈话时，可能感觉到延迟，并且可能以为通话出错了。
[0064]从带宽消耗的角度考虑，即使在浏览器/客户端2和服务器I之间没有实际的信息被通信，大量长轮询请求和空的长轮询响应被反复来回发送。这不仅引起带宽的消耗，也在浏览器/客户端2和服务器I中引起了处理负担。
[0065]多个HTTP连接被建立和释放(在图1所示该例中为三个)。HTTP连接的建立也很昂贵并引起了延迟。
[0066]上述例子也可应用于WebSocket的单向REST。不同的仅仅是其仅有一个WebSocket连接，而不是三个TCP连接。由HTTP连接引起的劣势消失了，然而由长轮询引起的问题仍然存在，例如，延迟、带宽消耗和处理负担。
[0067]图2示出现有技术的一种浏览器/客户端接收呼入的示意图。
[0068]在图2所示该例中，浏览器/客户端2有呼入，但是由于在呼入这个事件发生的时候没有可用的长轮询请求，服务器I不得不延迟通知浏览器/客户端2。与图1所示一样，延迟可能和在两个长轮询请求间的整个时间间隔一样长。
[0069]对该特定情形，在拨打被叫方的号码之后，呼叫方在听到回铃音(Ring BackTone)时可能感觉到延迟，因为回铃音是在得到180铃音(180Ringing)之后所播放的,