VoIP（Voice-over-Internet-Protocol）的时代已经到来，藉由将电话与资料通讯两个世界合而为一，可以透过成本低廉的网际网路连结，以串流方式传送封包化的语音及传真资料。此一从线路交换转换到封包交换网路的转移过程正在如火如荼地进行，让相关应用得以在相同的架构下，从单纯的语音传输扩展到其它型态的资料传送。然而，这些嵌入式设计所面临的挑战，在于如何挑选出成本效益高、布署容易、又能够针对市场需求提供具有扩充性的解决方案。更具体的说，嵌入式解决方案的一项优势是使用一个能够实现低通道数量VoIP解决方案之外，还有充足空间来增加像是视讯、音乐、影像及系统控制之类附加价值的处理器。本文将介绍上述的解决方案。

何谓VoIP

现今的语音网路，如PSTN（Public Switched Telephone Network；公众交换电话网路），是利用数位交换技术来建立发话者与受话者之间的专用连结。虽然这种连结方式只能提供有限的频宽，但它确实提供了可接受程度的品质，而不须动用到复杂的编码演算法。

VoIP则是使用网际网路协定，在网际网路或私人网路上传送数位化的语音流量，其IP封包含有一控制标头（header）及一资料负载（payload），标头为封包提供了网路导引资讯，而资料负载则携带着压缩过的语音资料。

与线路交换电话不同，资料传输为封包方式，因此资料的片段（chunk）须经过封包化与压缩， 再透过网路来传送，最后在接收端上重新被组合还原。如此一来，发射端与接收端之间就不须要专属的连结。

封包化对于透过网路来传送“资料”（例如JPEG档案或是email）而言，是很合适的作法，因为此方式的传送会是属于“最大努力（best-effort）”，网路能有效的在相同的媒体上搬移来自多个来源的资料。然而，对于语音应用而言，“最大努力”的传送方式并不恰当，因为在接收端上解码后的音频讯号品质，可能会受到封包在网路上传送时不定的延迟时间所影响，而变的令人无法接受。这也是为何VoIP协定，会将重点放在透过QoS来提供一固定份量的网路频宽，以避免延迟所造成的语音品质下降。

语音的封包化须要在语音资料块（block）上加入封包头（header）及封包尾（trailer）资讯，但封包化的额外负担必须尽量的减小以避免延迟增加。因此，在处理上必须于传送延迟与网路频宽有效运用两者间取得平衡。当然，较小的封包大小能传送的更频繁，较大的封包则会须要较长时间来组合。不过，在较大的封包中，由于封包头及封包尾会由较多的语音资讯所分摊，因此它们使用的网路频宽会比小封包来得少。

由于网路的特性，资料的传送速率会有不小的变化，此变化就是大家所熟悉的抖动量（jitter）。要将抖动量移除，可以将封包予以足够长的缓冲以确保最慢的封包也能够即时到达并被依正确的顺序解码开来。当然抖动量缓冲器会对系统增加一全面性的延迟。

延迟之所以是一项重要的参数，在于它代表了透过IP系统所导致的时间延误。单向的延迟指的是一个字从被说出一直到通信话对方听到所须的时间，往返延迟则是将两个单向延迟加起来的总合。对于北美的PSTN电话系统而言，往返延迟低于150ms。当然，越低的延迟值会让通话的品质表现越自然。

对于VoIP系统而言，单向延迟的可接受范围达到200ms之谱。造成该VoIP系统延迟的最大因素，是通话双方的网路及闸道器（gateway）。语音编解码器也会造成一些延迟的增加，但相对之下通常是较小的（＜20ms）。

当语音网路应用的延迟很大时，回音消除及重叠消除就成了最大的技术挑战。回音消除与感受到的品质有直接的关系，当往返延迟超过50ms时会成为一重要问题；语音重叠则是在单向延迟大于250ms时会造成问题。

现有和即将出现的VoIP相关应用

由于网路是用来做为传输的机制，VoIP系统的重要优点之一，就在于每一通讯时段（session）的成本会较低。此外，VoIP通话方式能让网路营运商避免掉与线路交换电话系统相关的大部份互连费用，而完成VoIP通话只须非常小的基础建设的增加，亦即利用现有已布署的家用或商用电脑的网路。另一个低成本的原因，是由于数据网路营运商通常都有未用到的频宽，因此增加VoIP服务所带来的额外负担基本上是微不足道的。

VoIP使用者总会认为所使用的连结是免费的，因为可以频繁地与全世界的各个角落通话，费用却只要每分钟几分钱。然而实际上使用者须向网际网路服务提供厂商缴交月费，只不过这笔费用可以由资料及语音服务所共同负担。

透过VoIP，不仅服务的费用比线路交换方式来的便宜，更能提供许多新的功能。举例来说，PSTN上的来电可以被自动转接到使用者的VoIP电话，只要该V​​oIP电话有接到网路节点上。此优点在能够全球通行的行动电话上特别有其意义，因为不会有漫游费用的产生。换句话说，使用者所在的地点从VoIP的角度来看是没有差异 的，因为该地点只不过是代表着另一网路连结点。这让符合802.11标准的VoIP手机特别吸引人，因为透过此特性，全球WiFi热点上的通话可以不用再担心通讯基础建设与传送标准的相容性问题。

到目前为止所讨论到的话题虽然围绕在透过IP来传送语音，但事实上也可延伸到其它型态的资料通讯。毕竟，一旦资料被数位化与封包化，内容是什么已不太重要了。 VoIP基础建设能够实现各种的新型网路即时应用，像是：

深入检视VoIP系统

如(图一)所示，为VoIP系统中的四大构成元件：讯号 （signaling）、编码/解码器、传输（transport）机制，以及交换式闸道器（switching gateway）。其中讯号包含了节点之间连结的建立、维护及终止。

《图一 VoIP系统四大构成组件》

为了降低网路频宽需求，音讯及视讯在传送之前及接收后必须加以编码与解码的处理，此压缩及转换过程，必须根据各种的音讯及视讯串流的编解码标准做为处理依归。

经过压缩的封包必须根据一个或多个传送协定在网路中流动，交换闸道器能确保封包在目的地上另一IP型态的系统或PSTN系统中具有互用性。当到达最后的目的地时，封包会被解码并换为音讯讯号，再透过接收端的听筒或喇叭播放出来。

(图二)详细说明了OSI（Open System Interconnection；开放系统连结）模型中各阶层所用到的一些协定，这些协定解释了网路的框架。

《图二 OSI模型中各阶层所用到的协议》

时段（session）控制：H.323 vs. SIP

VoIP系统中的第一个需求为时段控制协定，借以建立存在性（presence）及找出使用者，并设定、修改及终结时段。目前普遍使用中的协定有两种。就先后性来说，H.232为第一种出现的协定，但后起的SIP（Session Initiation Protocol；时段启始化协定）很快的取而代之成为主要的标准。接下来，将分别深入了解此两套协定。

H.323

H.323原本是针对即时多媒体（语音及视讯）会议及辅助资料传送所制定的ITU-T（ITU电信标准化部门）标准，该标准目前已快速发展成能够符合VoIP网路的需求。技术上来说，它是一个能容纳多组必要与选项网路及媒体编解码标准的容器，其连结讯号处理部份是由H.225协定来负责，功能特性协商则是由H.245来加以支援。

SIP(Session Initiation Protocol;时段起始化协定)

SIP是由RFC 3261下的IETF（Internet Engineering Task Force；网际网路工程任务小组）所制定，虽然有许多部份与H.323有所重叠，但SIP比较新且是专为IP电话及其它网际网路服务所开发出来的，因此该标准通常被视为主流的解决方案。

SIP是与SDP（Session Description Protocol；时段叙述协定）一起用来辨认出使用者，并负责提供特性协商及通话管理。 SDP本质上是用来在时段宣布（session announcement）及邀请（invitation）阶段中，叙述串流媒体启始参数的一种格式。某种程度而言，SIP/SDP就相当于H.323标准中的H.225/H.245协定。

SIP可以使用于只有两个端点（endpoint）的系统中，而不须要伺服器基础建设。不过，在公众网路中，会使用到特殊的防火墙及注册伺服器来建立连结。在这样的设立中，每一个用户会在伺服器中注册，以便来话者可以在网际网路上的任何角落找到该用户。

传输协定

上文讨论过的讯号处理协定，会负责网路上的多媒体时段设定。一旦连结建立起来，媒体便会根据一种或多种传输协定（像是UDP或TCP等）流动于网路节点间。

UDP（User Datagram Protocol；使用者资料包协定）

UDP是一种只负责将封包​​广播传送出去的网路协定，其中并没有来自接收端的封包已接收到回应通知。也就是说，此类传送并没有保障，因此在网路的负载巅峰时间上，语音传送如果只使用UDP，效果可能不会很理想，这就是为何除了UDP外，通常还会有像是RTP之类的媒体传输协定在其上面执行。

TCP（Transmission Control Protocol；传送控制协定）

TCP使用了用户/伺服器通讯模型，用户要求（同时也被提供）来自网路上另一台电脑的（伺服器）服务，每一个用户要求都会被个别处理，与先前的要求完全无关，如此可确保其它的通道可以使用到空闲的网路通路（network path）。

TCP能产生出较小的封包，透过网际网路传送出去，并由通话另一端的TCP层所接收，并将这些封包重新组合还原成原来的讯息。 IP层可处理每一个封包的位址栏，以确保封包能被送到正确的目的地。

相对于UDP，TCP就能够保障接收端完整的接收到封包。不过，由于其作法是容许封包的重传，所造成的延迟对于即时语音来说并不合适，这是因为重传而迟到的封包与遗失封包所造成的负面影响其实没有太大差别。由于此一特性，TCP并不被视为即时串流媒体传送的适当传输选择。

媒体传输

如前面所提到，就即时通讯而言，直接在传输协定上传送媒体资料并不是有效率的作法，因此通常是由媒体传输层来负责有效率的资料处理。

RTP（Real-time Transport Protocol；即时传输协定）

《图三 RTP框架的封包头架构及封包内容》

RTP为即时封包化的音讯及视讯资料提供传递的服务，是在IP网路上传输即时资料的标准方式。该协定存在于UDP上，以便将封包头的额外负担降到最低，但这相对的会有其附带的代价，就是无法保证封包次序的可靠性。与TCP相比，RTP的可靠度较低，但由于封包头的额外负担比起TCP来说小了很多，因此在封包的传送上延迟也较小。

为了维持一定水准的QoS，RTP为每一个送出的封包提供了时间戳记（time stamp）、顺序编码（sequence numbering）以及传递确认讯息。它同时也支援了多种纠错机制以增加可靠性，并具有某些基本的安全选项来进行封包加密处理。

《图四 可靠性与效能比较图》

RTP RTCP控制协定)

RTCP为一辅助型态的协定，用来沟通控制讯息，如寄送与遗失的封包数量、抖动量、延迟及端点叙述等。其最大的价值在于时段时基（session timebase）的管理，或是RTP串流的QoS分析等。该协定也提供了后门通道（backchannel），用来限制RTP封包的重传动作。

媒体编解码器

VoIP协定堆叠的最后一个构成元件负责处理实际在传输中的媒体，有不少的音频及视频编解码标准可适用于媒体传输层。

有效的语音编解码对于网路频宽使用率的最佳化是很重要的，而语音编解码就是用来压缩/解压缩语音资料封包。所有的压缩技术都必须在品质及频宽之间做一取舍，不过，有些考量因素可做为判断所需语音编解码器的依据，像是系统频宽的使用效率有多高、处理封包遗失的处理方式，以及有哪些成本会牵涉其中（如智慧财产权等）。

由于语音交谈中大部份的时间都属于所谓的“呆时（dead time）”，也就是双方都没有在说话的状态，因此编码器可针对此一事实现象，在该时段中不传送任何资料。为此，“静默压缩（silence compression）”就必需包含一侦测语音活动的方式、一可在没有语音活动时停止传送资料的方式，以及一能够产生舒适杂讯（comfort noise）以确保当双方都没有在说话时，线路上也不会变得完全安静的方法。

在一标准的线路交换式电话系统中，有几个原因会导致回音而降低服务品质，最常见的原因为线路交换式PSTN网路上的阻抗不匹配（线路回音；line echo），另一个常见的原因则是电话上麦克风与喇叭之间的音频耦合（音频回音；acoustic echo）。线路回音在网路中有两线对四线转换的场合中（比方说，类比讯号转为T1系统的地方）相当容易发生。

由于VoIP系统可能会连结到PSTN，因此必须能够应付线路回音。此外，在IP电话的麦克风与喇叭之间的回授，则会造成音频回音的出现。

回音消除标准（如G.168）可将系统中的回音除去，且可针对线路回音、音频回音或两者同时进行最佳化，而消除的效果则是直接由所采用的演算法之品质来决定。

回音消除的一个重要参数，是其操作上所采用的封包长度。简单的说，回音消除器会保留一份传送讯号的复本，在该讯号传出的特定时间后，回音消除器会试图将传送出去的讯号与回来的反射讯号进行关联比对（correlate）及相减。当然，此接收的讯号为已经过延迟，且在振幅上也变小。一般的关联比对窗（correlate window）长度为32ms、62ms或128ms。当回音超出关联比对窗的外围时，回音消除器就无法正确处理该回音。

VoIP之实际应用

传统的VoIP嵌入式解决方案是使用了两个处理器核心来提供VoIP功能，Blackfin处理器则提供了统一核心架构的聚合解决方案，由讯号处理单元负责语音处理，而RISC MCU则负责处理网路及使用者界面。此一提供完整VoIP功能于一聚合处理器的能力，提供的好处包括单一化的软体发展环境​​、较快速的系统除错开发，及较低的整体系统成本。

这些处理器必须能为VoIP的开发提供必要的整合度、性能及低功耗。该晶片需具有多组整合串列埠（可不须透过额外元件而直接连接到音讯类比/数位及数位/类比转换器）、外部记忆体控制器、用来接上LCD或视讯编解码器的平行周边介面（PPI）、以及10/100BaseT 乙太网路MAC​​。如有需要，还可以透过外部记忆体介面提供第二组的乙太网路MAC​​。

一个包含语音及网路堆叠（networking stack）在内的通讯通道，只须使用低于75MHz的处理器频宽。许多同类的VoIP方案通常在性能上容易出现瓶颈，且不具备增加功能及产品区隔特性的能力。由于多媒体压缩与解压缩的必要性日趋提高，因此超过600MHz的性能才可容许充裕的处理能力来实现各类的VoIP产品。

VoIP的衍生产品

对于VoIP应用来说，基于Blackfin的设计主要适用于高品质、低通道数量的VoIP解决方案，并提供足够的处理能力空间来增加类似音讯、视讯、影像等的传输，以及系统的整体控制。以下为市场上一些现有的VoIP产品，范围从开放来源解决方案到大量OEM参考设计都涵盖在内。

Blackfin/（Linphone）

Blackfin VoIP系统可以透过uClinux平台上的开放软体来进行设计，uClinux是由相当普及的GNU-Linux OS所发展出的嵌入式版本。线路电话为此类的GPL授权软体套件包之一，已被套用到uClinux上供处理器的开发使用，该软体套件包是基于SIP协定，因此能够让Blackfin参考设计和任何的SIP相容端点进行通讯。在具有适当SIP伺服器及闸道器基础建设的公众网路中，此系统甚至可以和PSTN节点上的电话连结。就语音编码与解码而言，目前使用Blackfin设计的有线电话成品能支援G.711（A-law及μ-law）、GSM及Speex。

参考设计中使用到的主要元件为：

Linux TCP/IP 网路堆叠

包含必要的传输与控制协定，如TCP与UDP等。

linphone

主要的VoIP应用，包括在Blackfin上开发出的G.711与GSM编解码器成品等。另外还有一套能在桌上型电脑上使用的图形化使用者界面（GUI）软体，以及指令键入式应用软体以供不具图形化能力的嵌入系统使用。

oRTP

针对线路电话所开发的RTP堆叠产品,可在LGPL授权下提供。

oSIP

具有执行绪安全（thread-safe）能力的SIP协定成品，可在LGPL授权下提供。

Speex

Speex编解码器的开放来源参考成品，针对Blackfin最佳化的定点式Speex成品已被加入主线码分支（mainline code branch）中。

Fusion Voice Gateway

Fusion Voice Gateway为Unicoi Systems所推出的完整语音闸道器/终端转接器（Voice Gateway/Terminal Adapter）参考设计，由于在同一颗核心处理器上可执行路由器功能（router）与全功能的SIP电话，因此客户可在很短的时间内利用Fusion Voice Gateway开发出终端转接器并推出上市。

Fusion Voice Gateway的BOM包括G.168回音消除及多种G.7xx语音编解码器。 Fusion参考设计还整合了9组路由器（router）、4埠乙太网路交换机、与VoIP闸道器等功能，以提供全功能的电话与路由器功能。

Blackfin BRAVO VoIP参考设计

对于从事多功能高性能与低成本的VoIP桌上型电话、视讯电话及电话转接器的OEM厂商来说，完整的系统解决方案在设计上需包含VoIP应用所须的完整软体套餐，并借由API以方便使用者进行核心系统功能的客制化与控制。

就音频而言，该设计能支援多种G.7xx音频编解码器、符合G.168标准的网路回音消除，以及音频回音消除等，以强化音讯的清​​晰度。在选项上，可以将RF收发器整合到设计中，以提供无线音频的能力。此设计同时支援了H.323及符合SIP的软体堆叠。

在视讯前端上，宽频音讯/视讯通讯参考设计支援了高达30fps的CIF视讯功能，包括ITU标准H.263及H.264视讯编解码器、子母画面、具有重叠效果的高解析度影像，合成（alpha）及去背功能（chroma keying）、以及防闪烁（antiflicker）滤波等。

音讯编解码器

G.711

与这里所介绍的其它几个标准相比，1988年所推出的G.711为一简单的标准。该标准所使用的唯一压缩为companding（使用μ法则或A法则标准），该标准将每一个资料取样压缩为8位元，产生出64kbps的输出位元率。根据H.323的规范，必须以G.711做为其语音通信的基准。

G.723.1

G.723.1是以ACELP所发展出来的双位元率编解码器，该标准在1996推出，主要的诉求为VoIP的应用。 G.723.1的编码框架为30mS，而每一个框架能被编码为20或24位元组，以分别转为5.3kbps及6.3kbps的串流。位元率能透过语音活动侦测及舒适杂讯产生等技术来有效的降低。此编解码技术能针对框架遗失及位元错误等网路问题，提供良好的免疫力。此语音编解码标准为H.324系列标准中所规定的视讯会议应用的一部份。

G.729

G.729为1996年所出现的另一个语音编解码标准，该标准将语音切割为10ms的框架，借以降低延迟程度。 G.729使用了名为Conjugate Structure ACELP （CS-ACELP）的演算法，并将8kHz取样的16位元讯号透过10ms的框架压缩为8kbps的标准位元率，该标准还支援6.4kbps与11.8kbps资料速率。此外，G.729也提供了语音活动侦测及舒适杂讯产生。

GSM

GSM语音编解码器在全世界的行动电话系统中都有其发挥的舞台，负责管控这些标准的组织单位是欧洲电信标准协会（ETSI），事实上在这些标准中是有其演化过程的，最早出现的版本为GSM全速率（GSM-FR），该标准采用了由CELP衍生出的Regular Pulse Excited Linear Predictive Coder （RPEL​​PC；常态脉冲激励线性预测编解码器），输入的语音讯号被切割为20ms的框架，再将每一个框架编码为260位元，以产生出13kbps的总位元率。市面上有免费的GSM-FR产品，可在某些限制规定下使用。

Speex

Speex为Xiph.org所推出的音频编解码器，其目标是要提供一完全没有专利考量的语音解决方案。就像许多其它的语音编解码器，Speex为基于CELP并附带余数（residue）编码技术，该标准可接受8kHz、16kHz及32kHz的线性PCM讯号，并可将它们编码成为从2到44kbps范围内的位元率。 Speex能够容忍网路错误，且支援语音活动的侦测。除了容许可变的位元率外，Speex的另一个独特优点为立体声的编码能力。Speex.org可对外提供Speex的原始程式，包括浮点运算参考设计及定点运算的版本。

视讯编解码器

H.261

此一标准在1990年推出，为第一个受到普遍采用的视讯编解码。该标准导入了将影像图框（frame）分割为16×16巨块（macroblock）、并有图框间追踪以决定动态补偿的技术观念，主要的市场目标是在于ISDN线路上（p×64kbps，其中p的范围是1到30）的视讯会议应用。其输入图框一般是30fps的CIF（352×288），输出的压缩图框在10 fps时会占用64～128Kbps的频宽。虽然目前仍有在使用中，但在大部份的场合中该标准早已被其后继者，如H.263所取代。不过，在H.323中仍然阐述必须以H.261做为视讯通信的基准（baseline）。

H.263

此编解码器为目前视讯会议中最为普遍采用的标准，其位元率表现优于H.261，输入的来源通常是30fps的QCIF（176x144）或CIF，输出位元率在10fps的条件下则可低于28.8Kbps，并提供与H.261相同的性能表现。因此，相对于H.261必须透过ISDN线路才能实现，H.263可使用一般的电话线路来传送。 H.263在视讯电话及网路监控系统的产品市场中非常适用，在以IP为基础的应用中受到广泛采用。

结语

很明显的，VoIP技术具有全面改革大众通信方式的潜力，不论使用者是在家中、在工作地点、插入式（plu​​gged in）连线、无界限（untethered）连线、视讯开启，或只是单纯的音讯通讯​​。处理器的多样化支援可让VoIP逐渐普及于嵌入式环境中，此一事实，将会为尚未享受到此令人兴奋科技的许多新市场创造出有附加价值的功能。