WebRTC 介绍 架构 等等

参考：

http://www.csdn.net/article/2012-08-14/2808592

http://www.leiphone.com/0925-ce6093-webrtc.html

http://www.infoq.com/cn/news/2011/06/google-webrtc

WebRTC 百度 百科

Dongdong Deng <LibFetion@gmail.com> 写的WebRTC ppt http://webrtcbook.com
Sam Dutton(Google Chrome Developer Relations) 写的WebRTC介绍

Harald Alvestrand写的RTCWEB Architecture

Colin Perkins – University of Glasgow写的WebRTC PPT

WebRTC :Ericsson Review 1.2012

WebRTC简介

WebRTC（Web Real-Time Communication，网络实时通信）项目的最终目的主要是让Web开发者能够基于浏览器（ChromeFireFox...）轻易快捷开发出丰富的实时多媒体应用，而无需下载安装任何插件，Web开发者也无需关注多媒体的数字信号处理过程，只需编写简单的Javascript程序即可实现，W3C等组织正在制定Javascript
标准API，目前是WebRTC 1.0版本，Draft状态；另外WebRTC还希望能够建立一个多互联网浏览器间健壮的实时通信的平台，形成开发者与浏览器厂商良好的生态环境。同时，Google也希望和致力于让WebRTC的技术成为HTML5标准之一，可见Google布局之深远。

WebRTC提供了视频会议的核心技术，包括音视频的采集、编解码、网络传输、显示等功能，并且还支持跨平台：windows，linux，mac，android。
WebRTC是一项在浏览器内部进行实时视频和音频通信的技术，是谷歌2010年以6820万美元收购Global IP Solutions公司而获得一项技术.
谷歌2011年6月3日宣布向开发人员开放WebRTC架构的源代码。这个源代码将根据没有专利费的BSD（伯克利软件发布）式的许可证向用户提供。目前，开发人员可访问并获取WebRTC的源代码、规格说明和工具等。

Google希望开源的WebRTC技术能够获得越来越多的浏览器厂商支持，WebRTC的网站已经宣布将在Chrome、Firefox和Opera上实现相应的API接口。Opera首席技术官H kon Wium Lie对媒体表示，Google能够把价值不菲的代码贡献出来非常了不起，Opera一直希望能够在浏览器中实现实时通信技术。

目前有关Web实时通信的技术标准正在制定当中，W3C的Web Real-Time Communication工作组在May 2011成立，
W3C的最新标准见http://dev.w3.org/2011/webrtc/editor/webrtc.html
最新版本是W3C Editor's Draft 16 January 2013
Editors:
Adam Bergkvist, Ericsson
Daniel C. Burnett, Voxeo
Cullen Jennings, Cisco
Anant Narayanan, Mozilla (until November 2012)
从作者所属公司及排序中可见 W3C 支持者的情况。

WebRTC实现了基于网页的视频会议，标准是WHATWG 协议，目的是通过浏览器提供简单的javascript就可以达到实时通讯（Real-Time Communications (RTC)）能力。

HTTP->WebRTC演进路径
HTTP(Pre AJAX):原始web，一页里发送请求后才返回另一页，如Geocities
AJAX(2004)：更新页面不需要刷新.如GMail.
Web Sockets(2008)：页面能建立双向通信（通过服务器中介)，如Trello。
WebRTC(2012)：页面之间的通信。

WebRTC的IETF标准

标准名称	Title	Date
draft-alvestrand-rtcweb-stats-registry-00	A Registry for WebRTC statistics identifiers	2012/9/24
draft-burman-rtcweb-h264-proposal-00	H.264 as Mandatory to Implement Video Codec for WebRTC	2012/10/15
draft-dbenham-webrtc-videomti-00	H.264/AVC as Mandatory-to-Implement Video Codec for RTCweb	2012/10/15
draft-ietf-rtcweb-audio-01	WebRTC Audio Codec and Processing Requirements	2012/11/22
draft-ietf-rtcweb-rtp-usage-05	Web Real-Time Communication (WebRTC): Media Transport and Use of RTP	2012/10/22
draft-jesup-rtcweb-data-protocol-03	WebRTC Data Channel Protocol	2012/9/7
draft-marjou-rtcweb-video-codec-00	Video codec for WebRTC.	2012/10/15
draft-nandakumar-rtcweb-sdp-00	SDP for the WebRTC	2012/10/15
draft-ohlsson-rtcweb-sdes-support-01	Support of SDES in WebRTC	2012/8/20
draft-reddy-rtcweb-mobile-00	Problems with WebRTC in Mobile Networks	2013/1/14
draft-yan-rtcweb-desktop-cloud-00	WebRTC Realization in Desktop Cloud	2012/9/12

WebRTC的W3C标准
W3C的最新标准见http://dev.w3.org/2011/webrtc/editor/webrtc.html

WebRTC架构图



架构图颜色标识说明：
（1）紫色部分是Web开发者API层；
（2）蓝色实线部分是面向浏览器厂商的API层
（3）蓝色虚线部分浏览器厂商可以自定义实现

Web API——第三方开发人员用来开发基于Web的应用，如视频聊天。
WebRTC Native C++ API——浏览器厂商用于实现Web API的函数集。
Session Management——抽象session层，支持调用构建和管理层，由应用开发者来决定如何实现协议。
VoiceEngine——音频媒体链的框架，从声卡到网络。
iSAC——一种用于VoIP和流音频的宽带和超宽带音频编解码器，iSAC采用16 kHz或32 kHz的采样频率和12—52 kbps的可变比特率。
iLBC——用于VoIP和流音频的窄带语音编解码器，使用8 kHZ的采样频率，20毫秒帧比特率为15.2 kbps，30毫米帧的比特率为13.33 kbps，标准由IETF RFC 3951和3952定义。
NetEQ for Voice——动态抖动缓存和错误隐藏算法，用于缓解网络抖动和丢包引起的负面影响。在保持高音频质量的同时尽可能降低延迟。
VideoEngine——视频媒体链的框架，从相机像头到网络，从网络到屏幕。
VP8——来自于WebM项目的视频编解码器，非常适合RTC，因为它是为低延迟而设计开发的。
Image enhancements——消除通过摄像头获取的图片的视频噪声等。

Architecture layers
● Data transport
○ Data path establishment: NAT traversal using ICE
○ Transmission: UDP (TCP backup)
○ Congestion management

● Data encapsulation
○ RTP
○ Some non-RTP method for non-media data

● Data formats
○ Codec choices go here

● Connection management / signaling
● Presentation and control
● Local system support functions

Security in context
● All components (except the RTCWEBimplementing browser) must be assumed evil
● Browser that executes JS using RTCWEB is responsible for both its own security and that of
victims it can reach (such as other tabs in the same browser, or other devices on the same LAN)
● Keep trust to a minimum

Data Transport
● Data path establishment: NAT traversal using ICE
○ Secures against "voice hammer" attacks
● Transmission: UDP (TCP backup)
○ Relays are sometimes needed
● Congestion management is necessary
○ Self-fair
○ Plays well with others
○ Would be nice not to invent one here

Data framing and securing
● RTP exists. We will reuse it.
● We have no need to carry unencrypted data.
○ SRTP for media
○ DTLS for non-media data
● DTLS-SRTP key negotiation
○ SDES key negotiation allows for retrospective decoding of wiretap data, reveals key to Web browser
● Note: UI issues are important for security
○ Mostly not IETF specs, but IETF knowledge informs W3C discussions

Data formats
● Data formats must be negotiated
○ Any consenting adults can agree on a data format
● A mandatory to implement codec prevents interoperability failure
● Need to focus on requirements for the baseline case (where MTI would come into play)

Connection Management
● Needed for setup:
○ Negotiation of data formats, transport options and security parameters (incl keys)
● Needed while connected:
○ Reaction to changed connectivity and needs (ex: resolutions)
● Least controversial proposal: ROAP
○ Specify a format for JS-Browser exchange
○ Usable as browser-to-browser format
○ Possible to gateway to SIP and XMPP
● We expect innovation in what-connects-to-what
● Active area of discussion!

Other Local Functions
● User action needs to cause net communication
○ Local and remote media mute -> stop/start sending
○ Display window size change -> change resolution
● Functions are needed to achieve usable applications
○ Automatic Gain Control -> consistent audio levels
○ Acoustic Echo Cancellation -> no feedback loops
○ Dynamic jitter buffers -> consistent (low) playout times

WebRTC的各种应用场景











Jingle(XMPP)







这种媒体流连接如何混音？如果在终端上混音，如何支持多达几十方的会议?





Signalling: make me an offer
1. Caller sends offer.
2. Callee receives offer.
3. Callee sends answer.
4. Caller receives answer.

Signalling: find me a candidate
1. Caller creates RTCPeerConnection object.
2. If success, callback passed IceCandidate.
3. Callee sends IceCandidate to callee.
4. Callee creates a new remote IceCandidate, adds to remote description.
5. Ping!





REST



代码例

PeerConnection位于WebRTC Native C++ API的最上层，它的代码实现来源于libjingle（一款p2p开发工具包），目前被应用于WebRTC中。其中关键的两个类定义是：

class PeerConnectionObserver {
public:
virtual void OnError();
virtual void OnSignalingMessage(const std::string& msg);
virtual void OnAddStream(const std::string& stream_id,
int channel_id,
bool video);
virtual void OnRemoveStream(const std::string& stream_id,
int channel_id,
bool video);
};
该类定义了一个抽象的观察者。开发人员应该继承实现自己的观察者类。

class PeerConnection {
public:
explicit PeerConnection(const std::string& config);
bool Initialize();
void RegisterObserver(PeerConnectionObserver* observer);
bool SignalingMessage(const std::string& msg);
bool AddStream(const std::string& stream_id, bool video);
bool RemoveStream(const std::string& stream_id);
bool Connect();
void Close();
bool SetAudioDevice(const std::string& wave_in_device,
const std::string& wave_out_device);
bool SetLocalVideoRenderer(cricket::VideoRenderer* renderer);
bool SetVideoRenderer(const std::string& stream_id,
cricket::VideoRenderer* renderer);
bool SetVideoCapture(const std::string& cam_device);
};

具体的函数说明可以查看相应的API介绍。

正如Google所说的，它一直在参与制定和实现HTML 5标准中的视频会议和p2p通信部分，虽然还不是正式标准，但是我们可以从草案的示例中看到未来Web开发人员的使用情况：

// the first argument describes the STUN/TURN server configuration
var local = new PeerConnection('TURNS example.net', sendSignalingChannel);
local.signalingChannel(...); // if we have a message from the other side, pass it along here
// (aLocalStream is some GeneratedStream object)
local.addStream(aLocalStream); // start sending video
function sendSignalingChannel(message) {
... // send message to the other side via the signaling channel
}
function receiveSignalingChannel (message) {
// call this whenever we get a message on the signaling channel
local.signalingChannel(message);
}
local.onaddstream = function (event) {
// (videoElement is some <video> element)
videoElement.src = URL.getObjectURL(event.stream);
};

WebRTC架构组件介绍
(1) Your Web App
Web开发者开发的程序，Web开发者可以基于集成WebRTC的浏览器提供的web API开发基于视频、音频的实时通信应用。
(2) Web API
面向第三方开发者的WebRTC标准API（Javascript），使开发者能够容易地开发出类似于网络视频聊天的web应用。
这些API可分成Network Stream API、 RTCPeerConnection、Peer-to-peer Data API三类,。
Network Stream API
MediaStream：MediaStream用来表示一个媒体数据流。
MediaStreamTrack在浏览器中表示一个媒体源。
RTCPeerConnection
RTCPeerConnection: 一个RTCPeerConnection对象允许用户在两个浏览器之间直接通讯。
RTCIceCandidate ：表示一个ICE协议的候选者。
RTCIceServer:表示一个ICE Server。
Peer-to-peer Data API
DataChannel:数据通道( DataChannel)接口表示一个在两个节点之间的双向的数据通道 。
(3) WebRTC Native C++ API
本地C++ API层，使浏览器厂商容易实现WebRTC标准的Web API，抽象地对数字信号过程进行处理。
(4) Transport / Session
传输/会话层
会话层组件采用了libjingle库的部分组件实现，无须使用xmpp/jingle协议
a. RTP Stack协议栈
Real Time Protocol
b. STUN/ICE
可以通过STUN和ICE组件来建立不同类型网络间的呼叫连接。
c. Session Management
一个抽象的会话层，提供会话建立和管理功能。该层协议留给应用开发者自定义实现。

(5) VoiceEngine
音频引擎是包含一系列音频多媒体处理的框架，包括从视频采集卡到网络传输端等整个解决方案。
VoiceEngine是WebRTC极具价值的技术之一，是Google收购GIPS公司后开源的。在VoIP上，技术业界领先。
a. iSAC
Internet Speech Audio Codec
针对VoIP和音频流的宽带和超宽带音频编解码器，是WebRTC音频引擎的默认的编解码器
采样频率：16khz，24khz，32khz；（默认为16khz）
自适应速率为10kbit/s ~ 52kbit/；
自适应包大小：30~60ms；
算法延时：frame + 3ms
b. iLBC
Internet Low Bitrate Codec
VoIP音频流的窄带语音编解码器
采样频率：8khz；
20ms帧比特率为15.2kbps
30ms帧比特率为13.33kbps
标准由IETF RFC3951和RFC3952定义
c. NetEQ for Voice
针对音频软件实现的语音信号处理元件
NetEQ算法：自适应抖动控制算法以及语音包丢失隐藏算法。使其能够快速且高解析度地适应不断变化的网络环境，确保音质优美且缓冲延迟最小。
是GIPS公司独步天下的技术，能够有效的处理由于网络抖动和语音包丢失时候对语音质量产生的影响。
PS：NetEQ 也是WebRTC中一个极具价值的技术，对于提高VoIP质量有明显效果，加以AECNRAGC等模块集成使用，效果更好。
d. Acoustic Echo Canceler (AEC)
回声消除器是一个基于软件的信号处理元件，能实时的去除mic采集到的回声。
e. Noise Reduction (NR)
噪声抑制也是一个基于软件的信号处理元件，用于消除与相关VoIP的某些类型的背景噪声（嘶嘶声，风扇噪音等等… …）
(6) VideoEngine
WebRTC视频处理引擎
VideoEngine是包含一系列视频处理的整体框架，从摄像头采集视频到视频信息网络传输再到视频显示整个完整过程的解决方案。
a. VP8
视频图像编解码器，是WebRTC视频引擎的默认的编解码器
VP8适合实时通信应用场景，因为它主要是针对低延时而设计的编解码器。
PS:VPx编解码器是Google收购ON2公司后开源的，VPx现在是WebM项目的一部分，而WebM项目是Google致力于推动的HTML5标准之一
b. Video Jitter Buffer
视频抖动缓冲器，可以降低由于视频抖动和视频信息包丢失带来的不良影响。
c. Image enhancements
图像质量增强模块
对网络摄像头采集到的图像进行处理，包括明暗度检测、颜色增强、降噪处理等功能，用来提升视频质量。

For Web Developers
提供JS API来实现音视频采集，传输，显示的Web应用
navigator.getUserMedia
navigator.getUserMedia('audio,video', Stream);
MediaStream
MediaStreamRecorder record();
void stop();
PeerConnection
sendSignalingChannel()
receiveSignalingChannel()

Example1:
Record a short audio message and upload it to the server.
example1.txt:
http://www.kgdb.info/wp-content/uploads/2011/11/example1.txt

Example2:
PeerConnection Using example2.txt:
http://www.kgdb.info/wp-content/uploads/2011/11/example2.txt

For App Developers
Build WebRTC from source:
Create a working directory, enter it, and run:
$ gclient config http://webrtc.googlecode.com/svn/trunk $ gclient sync --force
sync will generate native build files for your environment using gyp
Build
$cd trunk
$make

Sample application:
a simple video chat client and server using the PeerConnection C++ API.

PeerConnection C++ API
PeerConnection.htm:
http://www.kgdb.info/wp-content/uploads/2011/11/PeerConnection.htm

代码库分析

一、 视频
WebRTC的视频部分，包含采集、编解码(I420/VP8)、加密、媒体文件、图像处理、显示、网络传输与流控(RTP/RTCP)等功能。
视频采集---video_capture
源代码在webrtcmodulesvideo_capturemain目录下，包含接口和各个平台的源代码。
在windows平台上，WebRTC采用的是dshow技术，来实现枚举视频的设备信息和视频数据的采集，这意味着可以支持大多数的视频采集设备；对那些需要单独驱动程序的视频采集卡（比如海康高清卡）就无能为力了。
视频采集支持多种媒体类型，比如I420、YUY2、RGB、UYUY等，并可以进行帧大小和帧率控制。
视频编解码---video_coding
源代码在webrtcmodulesvideo_coding目录下。
WebRTC采用I420/VP8编解码技术。VP8是google收购ON2后的开源实现，并且也用在WebM项目中。VP8能以更少的数据提供更高质量的视频，特别适合视频会议这样的需求。
视频加密--video_engine_encryption
视频加密是WebRTC的video_engine一部分，相当于视频应用层面的功能，给点对点的视频双方提供了数据上的安全保证，可以防止在Web上视频数据的泄漏。
视频加密在发送端和接收端进行加解密视频数据，密钥由视频双方协商，代价是会影响视频数据处理的性能；也可以不使用视频加密功能，这样在性能上会好些。
视频加密的数据源可能是原始的数据流，也可能是编码后的数据流。估计是编码后的数据流，这样加密代价会小一些，需要进一步研究。
视频媒体文件--media_file
源代码在webrtcmodulesmedia_file目录下。
该功能是可以用本地文件作为视频源，有点类似虚拟摄像头的功能；支持的格式有Avi。
另外，WebRTC还可以录制音视频到本地文件，比较实用的功能。
视频图像处理--video_processing
源代码在webrtcmodulesvideo_processing目录下。
视频图像处理针对每一帧的图像进行处理，包括明暗度检测、颜色增强、降噪处理等功能，用来提升视频质量。
视频显示--video_render
源代码在webrtcmodulesvideo_render目录下。
在windows平台，WebRTC采用direct3d9和directdraw的方式来显示视频，只能这样，必须这样。
网络传输与流控
对于网络视频来讲，数据的传输与控制是核心价值。WebRTC采用的是成熟的RTP/RTCP技术。

二、音频
WebRTC的音频部分，包含设备、编解码(iLIBC/iSAC/G722/PCM16/RED/AVT、NetEQ)、加密、声音文件、声音处理、声音输出、音量控制、音视频同步、网络传输与流控(RTP/RTCP)等功能。
音频设备---audio_device
源代码在webrtcmodulesaudio_devicemain目录下，包含接口和各个平台的源代码。
在windows平台上，WebRTC采用的是Windows Core Audio和Windows Wave技术来管理音频设备，还提供了一个混音管理器。
利用音频设备，可以实现声音输出，音量控制等功能。
音频编解码---audio_coding
源代码在webrtcmodulesaudio_coding目录下。
WebRTC采用iLIBC/iSAC/G722/PCM16/RED/AVT编解码技术。
WebRTC还提供NetEQ功能---抖动缓冲器及丢包补偿模块，能够提高音质，并把延迟减至最小。
另外一个核心功能是基于语音会议的混音处理。
声音加密--voice_engine_encryption
和视频一样，WebRTC也提供声音加密功能。
声音文件
该功能是可以用本地文件作为音频源，支持的格式有Pcm和Wav。
同样，WebRTC也可以录制音频到本地文件。
声音处理--audio_processing
源代码在webrtcmodulesaudio_processing目录下。
声音处理针对音频数据进行处理，包括回声消除(AEC)、AECM、自动增益(AGC)、降噪处理等功能，用来提升声音质量。
网络传输与流控
和视频一样，WebRTC采用的是成熟的RTP/RTCP技术。

Google WebRTC官网上列表了使用WebRTC技术的四个理由：
互联网成功的一个关键因素是一些核心技术如HTML、HTTP和TCP/IP是开放和免费实现的。目前，在浏览器通信领域还没有免费、高质量、完整的解决方案。WebRTC就是这样的技术。
该技术已经集成了最佳的音频、视频引擎，并被部署到数以百万级的终端中，经过超过8年的磨练。Google不会从该技术中收取费用。
包含了使用STUN、ICE、TURN、RTP-over-TCP的关键NAT和防火墙穿越技术，并支持代理。
构建在浏览器中，WebRTC通过提供直接映射到PeerConnection的信号状态机来抽象信号处理。Web开发人员因此可以选择适合应用场景的协议（例如：SIP、XMPP/Jingle等等）。
来源： http://www.infoq.com/cn/news/2011/06/google-webrtc

思考：Session Management 即 会话控制协议，如SIP、H.323 不在WebRTC的API库中，那么WebRTC只是做了媒体面的功能，不可能支持QQ这样的Message业务、在线地址簿。
也许未来会集成SIP协议栈在内，需要为服务器提供XMPP协议库。
或者终端与服务器之间采用http或自定义协议，而服务器之间采用SIP、XMPP协议。
webRTC主要是提供了音、视频编解码的免费源代码、SRTP、集成STUNICE技术、安全技术、及一个WEB终端的API库架构，让应用开发人员能够通过HTML标签和JavaScript API就实现Web音频、视频通信功能。将促进互联网创新的实现，大量减少开发者的繁重开发任务，降低
创业型公司 创新的成本，

如果它要做点到点的通信，需要P2P连接。但实际上这样的应用模式（按IP地址来通信）是没有意义的。 而且它无法支持多方通信。
可行的应用模式仍需要IMPresence服务器支持，提供 多方通信、用户标识注册、增强地址簿（不光是电话号码）、在线状态、地理位置信息、与社交网络互通 等功能。仍需要STUNICE Server来做到跨越私网的通信。

WebRTC是一个支持网络浏览器进行实时语音对话或视频对话的软件架构。WebRTC实现了基于网页的视频会议，同时通过无缝通讯和P2P全方位改变人们生活和工作的方式。

WebRTC是Web Real-Time Communication（网络实时通讯）的缩写，是一项在浏览器内部进行实时视频和音频数据通信的技术，有望成为HTML5标准之一。 WebRTC的这些特性可以使网络应用进入一个新的阶段。
异步Javascript和XML使开发者能够无需重新加载即可更新网页内容，而WebRTC堪称近年来最大的一次技术革新，加入了很多交互特性，为网络带了很多革命性的新“天赋”，这些“天赋”定会使网络世界向前迈一大步。
如果说HTML5 已经让世人眼前一亮的话，那WebRTC 就是创新的集大成者。直接连接到其他浏览器为网络开发者提供了另一种新的可能性，用户间的直接互动革新了通讯和游戏应用的工作方式。现在的浏览器间要想实现直接通讯，必须借助第三方插件和专属服务器。而 WebRTC 拥有开放标准，使浏览器间直通很容易在互联网架构中实现。WebRTC 带来了诸多改进：越来越多的图像应用和视频应用开始支持移动浏览器；一些重大新闻能够第一时间通过手机传送到新闻机构；仅通过一行代码即可实现网页实时支持和反馈；无需软件实现文件分享。
在线实现视频、图像和音频分享跟浏览网页一样容易。开发者可以很轻易地将这些特性加入到产品中去。
WebRTC 的兴起之路也不得不考虑政治因素，P2P传输很难监管而且不好关闭。我们已经在某些场合见识了社交网络的威力，你能想象当社交网络插上了实时音视频通信传输的翅膀会擦出怎样的火花吗
WebRTC也会使电视会议和互联网技术市场大幅缩水，今后我们或许不会再需要Skype和Webex。将来， Skype、Cisco、和 Polycom的电视会议技术都将实现商品化。
互联网正在经历着新一轮创新浪潮，此次浪潮使多平台无缝通讯和P2P直接通讯成为可能.

问题：

这个标准建立起来后，很多传统的VoIP服务供应商将会逐渐衰落和死亡。那些一成不变的移动运营商将会面临用户的大量流失，因为他们会往新的服务提供商“迁移”。传统的固话销售和移动语音的使用将会慢慢消失，现在所流行的电话网络将会一去不复还。
回答：WebRTC本身没有提供什么新技术，只是提供了一个Web浏览器支持语音、视频应用的框架性标准与媒体面处理的免费代码。 未来利用webRTC推出新应用将非常容易。在它之前，互联网上已经有许多VOIP免费应用、许多免费代码库 可得到，PLMN走向衰亡是已经注定的，甚至被运营商所认可（LTE网络中已经没有CS域，只有基于VOIP的语音通信，只有RCS+IMS），webRTC会加速这个过程，但它并不是一个革命性的技术，不是杀手锏，杀手锏是LTEWiFi，正因为带宽提升，才导致Voip质量可以满足通信要求。

WebRTC堪称近年来最大的一次技术革新，加入了很多交互特性，为网络带了很多革命性的新“天赋”，而这些“天赋”使网络世界向前迈一大步。

当开发者希望使用音频或者视频通话时，可以直接使用已有的代码，唯一需要做的只需在移动设备上创建一个独立的应用程序。该标准提出后，许多传统的VoIP服务供应商将逐渐衰落和死亡。传统的固定销售（电话销售）以及传统的语音设备将被淘汰，电话网络的形式已一去不复还了。这对于移动运营商来说将面临一种新的挑战。