* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
RFC3261 - SIP: Session Initiation Protocol
RFC3323 - A Privacy Mechanism for the Session Initiation Protocol (SIP)
RFC3265 - Session Initiation Protocol (SIP)-Specific Event Notification
RFC3842 - A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
RFC3372 - Session Initiation Protocol for Telephones (SIP-T): Context and Architectures
RFC2976 - The SIP INFO Method
RFC3204 - MIME media types for ISUP and QSIG Objects
RFC3398 - Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
SIP(会话启动协议 Session Initiation Protocol)是由IETF提出并主持研究的一个在IP网络上进行多媒体通信的应用层控制协议，它被用来创建、修改、和终结一个或多个参加者参加的会话进程。SIP协议独立于其他会议控制协议，它在设计上独立于下面的传输层协议，因此可以灵活方便地扩展其他附加功能。SIP作为一个应用层的多媒体会话信令协议，可以被用来发起一个会话进程、在会话中邀请其他参加者加入会议，会话本身可以通过基于组播协议的会话通告协议（SAP）、电子邮件、网页通告、以及轻量级号薄访问协议（LDAP）等方式预先通告各个可能的参加者。SIP协议支持别名映射、重定向服务、ISDN和IN业务。它支持个人移动（personal mobility），即终端用户能够在任何地方、任何时间请求和获得已订购的任何电信业务。SIP协议可以通过MCU（Multipoint Control Unit）、单播联网方式、或组播方式创建多方会话，支持PSTN和因特网电话之间的网关功能。SIP协议可以与其他用于建立呼叫的信令系统或协议结合使用，它在设计上充分考虑了对其他协议的可扩展性。SIP协议不提供发言控制（floor control）、投票等会议控制功能，也不规定如何管理一个会议。但是SIP协议可被用来引发这些会议控制协议。SIP协议本身不具备资源预留功能，但可以向被邀请者们传达这方面的信息。
SDP(会话描述协议)描述流媒体初始化参数的格式，由IETF作为RFC 4566颁布。流媒体是指在传输过程中看到或听到的内容。
RTP是实时传输协议的缩写，用来定义在Internet上传输音频和视频的标准包格式。RTCP是实时传输控制协议的缩写，在RFC 3550中予以定义。RTCP与RTP联合工作，RTP实施实际数据的传输，RTCP则负责将控制包送至电话中的每个人，并就服务质量做出反馈。
IP PBX是一种基于IP的公司电话系统。这个系统可以完全将话音集成到公司的数据网络中，从而建立能够连接分布在全球各地办公地点和员工的统一话音和数据网络。IP PBX最显著特征是仅需要单一设备即可为用户提供语音、传真、数据和视频等多种通信方式。
STUN (Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)) 服务器允许所有的NAT客户终端 (如防火墙后边的计算机) 与局域网以外的VOIP服务商实现电话通话。通过STUN服务器，客户终端可以了解他们的公共地址、挡在他们前面的NAT类型和通过NAT与特定局部端口相连的因特网端口。这些信息将被用于建立客户终端与VOIP服务商之间的UDP通信，以便实现通话。STUN协议在RFC3489中予以定义。虽然是在UDP端口3478连接STUN服务器，但会暗示客户终端在另外一个IP和端口号上实施测试（STUN服务器有两个IP地址）。RFC 规定这个端口和IP是随意的。
ENUM是电话号码映射(Telephone Number Mapping) 的缩写。这个缩写的后面隐藏着一个伟大的创意：即通过最好和最廉价的路由途径，可以在世界任何地点使用同一个电话号码。ENUM是将一个电话号码与一个在 DNS（域名服务器）系统中公布的因特网地址相连接。ENUM号码的拥有者可以通过DNS地址规定电话的路由地址。而且还可以为不同类型的来电规定不同的路由途径。例如，如果来电方是传真机，您可以将此规定到一个不同的路由途径上。ENUM不需要来电方必须使用电话机。 您可以象注册域名一样注册ENUM号码。目前有许多注册机构和VOIP服务商免费提供这类服务。 ENUM是一个新标准，尚未广泛推广，但它将带来电信和个人移动性行业的一场新革命。
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
SIP协议是IETF多媒体数据和控制体系结构的一部分，与其它协议相互合作，例如：RSVP（Resource ReServation Protocol）用于预约网络资源，RTP（Real-time Transmit Protocol）用于传输实时数据并提供服务质量（QoS）反馈，RTSP（Real-Time Stream Protocol）用于控制实时媒体流的传输，SAP（Session Announcement Protocol）用于通过组播发布多媒体会话，SDP（Session Description Protocol）用于描述多媒体会话。但是SIP协议的功能和实施并不依赖这些协议。
传输层支持：SIP协议承载在IP网，网络层协议为IP，传输层协议可用TCP或UDP，推荐首选UDP。
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
- Call-ID 该字段用以唯一标识一个特定的要求或标识某一客户的所有标记。需要注意的是，一个多媒体会议可能会有多个呼叫，每个呼叫有其自己的Call-ID。例如，某用户可数次邀请某人参加同一历时很长的会议。用户也可能会收到数个参加同一会议或呼叫的邀请，其Call-ID各不相同。用户可以利用会话描述中的标识，例如SDP中的o（源）字段的会话标识和版本号判定这些邀请的重复性。Call-ID的一般格式为：Call-ID：本地标识@主机。Call-ID字符需区分大小写。
- From 所有请求和响应必须包含此字段，以指示请求的发起者。服务器将此字段从请求消息复制到响应消息。该字段的一般格式为：From:显示名<SIP-URL>;tag=xxxx。其中，显示名为用户界面上显示的字符，如果系统不予显示，应置显示名为“匿名(Anonymous)”。显示名为任选字段。tag称为标记，为16进制数字串，中间可带连字符“-”。当两个共享同一SIP地址的用户实例用相同的Call-ID发起呼叫邀请时，就需用此标记予以区分。标记值必须全局唯一。用户在整个呼叫期间应保持相同的Call-ID和标记值。
- To 该字段指明请求的接收者，其格式和From相同，仅第一个关键词代之以To。所有请求和响应消息必须包含此字段。字段中的标记参数可用于区分由同一SIP URL标识的不同的用户实例。由于代理服务器可以并行分发多个请求，同一请求可能到达用户的不同实例（如住宅电话等）。由于每个实例都可能响应，因此需用标记来区分来自不同实例的响应。需要注意的是，To字段中的标记是由每个实例置于响应消息中的。注意，在SIP中，Call-ID、From和To三个字段标识一个呼叫分支。在代理服务器并行分发请求时，一个呼叫可能会有多个呼叫分支。
- Cseq Cseq称之为命令序号。客户在每个请求中应加入此字段，它由命令名称和一个十进制序号组成，该序号由请求客户选定，在Call-ID范围内唯一确定。序号初值可为任意值，其后具有相同Call-ID值，但不同命令名称、消息体的请求，其Cseq序号应加1。重发请求的序号保持不变。服务器将请求中的Cseq值复制到响应消息中，用于将请求和其触发的响应相关联。ACK和CANCEL请求的Cseq值（十进制序号）和对应的INVITE请求相同，BYE请求的Cseq序号应大于INVITE请求。服务器必须记忆相同Call-ID的INVITE请求的最高序号，收到序号低于此值的INVITE请求应在给出响应后予以丢弃。由代理服务器并行分发的请求，其Cseq值相同。严格来说，Cseq对于任何可由BYE或CANCEL请求取消的请求以及客户可连续发送多个具有相同Call-ID请求的情况都是需要的，其作用是判定响应和请求的对应关系。
- Via Via字段用以指示请求历经的路径。它可以防止请求消息传送产生环路，并确保响应和请求消息选择同样的路径，以保证通过防火墙或满足其它特定的选路要求。发起请求的客户必须将其自身的主机名或网络地址插入请求的Via字段，如果未采用缺省端口号，还需插入此端口号。在请求前传过程中，每个代理服务器必须将其自身地址作为一个新的Via字段加在已有的Via字段之前。如果代理服务器收到一个请求，发现其自身地址位于Via头部中，则必须回送响应“检测到环路”。当请求消息通过网络地址翻译点（如防火墙）时，请求的源地址和端口号可能被改变，此时Via字段就不能成为响应消息选路的依据。为了防止这一点，代理服务器应校验顶端Via字段，如果发现其值和代理服务器检测到的前站地址不符，则应在该Via字段中加入“receive”参数，如此修改后的字段称为“接收方标记Via头部字段”。??? 若代理服务器向多播地址发送请求，则必须在其Via头部字段中加入“多播地址(maddr)”参数，此参数指明该多播地址。
代理服务器或UAC收到Via头部字段时的处理规则是：
规则1：第1个Via头部字段应该指示本代理服务器或UAC。如果不是，丢弃该消息，否则，删除该Via字段。
规则2：如果没有第2个Via头部字段，则该响应已经到达目的地。否则，继续做如下处理。
规则3：如果第2个Via头部字段包含“maddr”参数，则按该参数指示的多播地址发送响应，端口号由“发送方”参数指明，如未指明，就使用端口号5060。响应的生存期应置为“生存期（ttl）”参数指定的值，如未指明，则置为1。
规则4：如果第2个Via字段不包含“maddr”参数，但有一个接收方标记字段，则应将该响应发往“received”参数指示的地址。
规则5：如果既无“maddr”参数又无标记，就按发送方参数指示的地址发送响应。
Via字段的一般格式为：
Via：发送协议 发送方；隐藏参数；生存期参数；多播地址参数；接收方标记，分支参数
发送协议的格式为：协议名/协议版本/传送层。发送方为发送方主机和端口号。隐藏参数(hidden)表示该字段由上游代理加密以提供隐私服务。生存期参数与多播地址参数配用。分支参数用于代理服务器并行分发请求时标记各个分支，响应到达时代理可判定是哪一分支的响应。
- Contact 该字段用于INVITE、ACK和REGISTER请求以及2xx、1xx和3xx消息，其作用是给出其后和用户直接通信的地址。INVITE和ACK请求中的Contact字段指示该请求发出的位置。它使被叫可以直接将请求（如BYE请求）发往该地址，而不必借助Via字段经由一系列代理服务器返回。对INVITE请求的成功响应消息可包含Contact字段，它使其后SIP请求（如ACK请求）可直接发往该字段给定的地址。该地址一般是被叫主机的地址，如果该主机位于防火墙之后，则为代理服务器地址。对应于INVITE请求的1xx响应消息中包含的Contact字段的含义和成功响应消息相同。但是，CANCEL请求不能直接发往该地址，必须沿原请求发送的路径前传。REGISTER请求中的Contact字段指明用户可达位置。该请求还定义了通配Contact字段“*”，它只能和值为0的“失效”字段配用，表示去除某用户的所有登记。Contact字段也可设定“失效”参数（任选），给定登记的失效时间。如果没有设定该参数，则用“失效”字段值作为其缺省值。如果两者均无，则认为SIP URI的失效时间为1小时。REGISTER请求的成功响应消息中的Contact字段返回该用户当前可达的所有位置。3xx响应消息，如用户临时迁移、永久迁移、地址模糊等消息中的Contact字段给出供重试的其它可选地址，可用于对BYE、INVITE和OPTIONS请求的响应消息。
Contact字段的一般格式为：
Contact：地址；q参数；动作参数；失效参数；扩展属性
地址的表示形式和To/From字段相同。q参数取值范围为[0，1]，指示给定位置的相对优先级,数值越大优先级越高。动作参数仅用于REGISTER请求,它表明希望服务器对其后至该客户的请求进行代理服务还是重定向服务。如果未含此参数，则执行动作取决于服务器的配置。失效参数指明URI的有效时间，可用秒表示，也可用SIP日期表示。扩展属性就是扩展名。
- Max-Forwards 该字段用于定义一个请求到达其目的地址所允许经过的中转站的最大值。请求每经过一个中转站，该值减1。如果该值为0时该请求还没有到达其目的地址，服务器将回送“483”(Too Many Hops)响应并终止这个请求。设置该字段的目的主要是为了出现环路时不会一直消耗代理服务器的资源。该字段的初始值为70。
- Allow 该字段给出代理服务器支持的所有请求消息类型列表。
- Content-Length 该字段表示消息体的大小，为十进制值。应用程序使用该字段表示要发送的消息体的大小，而不考虑实体的媒体类型。如果使用基于流的协议（如TCP协议）作为传输协议，则必须使用此消息头字段。消息体的长度不包括用于分离消息头部和消息体的空白行。 Content-Length值必须大于等于0。如果消息中没有消息体，则Content-Length头字段值必须设为0。SDP用于构成请求消息和2xx响应消息的消息体。
- Content-Type 该字段表示发送的消息体的媒体类型。如果消息体不为空，则必须存在Content-Type 头字段。如果消息体为空且Content-Type 头字段存在，则表示此类型的消息体长度为0 （如一个空的声音文件）。
- Supported SIP协议中定义的100类临时响应消息的传输是不可靠的，即UAS发送临时响应后并不能保证UAC端能够接受到该消息。如果需要在该响应消息中携带媒体信息，那么就必须保证该消息能够可靠的传输到对端。100rel扩展为100类响应消息的可靠传输提供了相应的机制。100rel新增加对临时响应消息的确认请求方法：PRACK。如果UAC支持该扩展，则在发送的消息中增加Supported:100rel头域和字段。如果UAS支持该扩展，则在发送100类响应时增加Require:100rel头域和字段。UAC收到该响应消息后需要向UAS发送PRACK请求通知UAS已收到该临时响应。UAS向UAC发送对PRACK的2XX响应消息结束对该临时响应的确认过程。如果某一UA想要在发送的临时响应消息中携带SDP消息体，那么UAC和UAS都必须支持和使用100rel扩展以保证该消息的可靠传输。
- User-Agent 该头字段包含有发起请求的用户终端的信息。显示用户代理的软件版本信息可能会令用户在使用有安全漏洞的软件易受到外界攻击，因此，应该使User-Agent头字段成为可选配置项。
- Expires 该头字段指定了消息（或消息内容）多长时间之后超时。
- Accept-Language 该头字段用在请求消息中，表示原因短语、会话描述或应答消息中携带的状态应答内容的首选语言类型。如果消息中没有Accept-Language头字段，则服务器端认为客户端支持所有语言。
- Authorization 该字段包含某个终端的鉴权证书。
首先介绍一下终端向服务器端请求认证的一般过程：
终端发起请求时如果服务器端需要对用户进行认证，那么会在本地产生本次认证的NONCE，并且通过认证请求头域将所有必要的参数返回给终端从而发起对用户认证过程。
终端收到认证请求消息后根据服务器端返回的信息和用户配置等信息采用特定的算法生成加密的RESPONSE，并且通过新的请求消息发送给服务器端。
服务器端在收到带有认证响应的新的请求消息后首先检查NONCE的正确性。如果NONCE不是本地产生则直接返回失败。如果NONCE是本地产生，但是认证过程已经超时，则服务器端会重新产生NONCE并重新发起对用户的认证过程。老的NONCE会通过CNONCE参数返回。
NONCE验证通过后服务器端会根据NONCE、用户名、密码（服务器端可以根据本地用户信息获取用户的密码）、URI等采用和终端相同的算法生成RESPONSE，并且对此RESPONSE和请求消息中的RESPONSE进行比较，如果二者一致则用户认证成功，否则认证失败。
Authorization字段的一般格式为：
Authorization：认证方式 USERNAME，REALM，NONCE，RESPONSE，URI，CNONCE，ALGORITHM
认证方式：有DIGEST、BASIC、CHAP-PASSWORD、CARDDIGEST等认证方式。DIGEST为HTTP-DIGEST认证方式。
USERNAME：被认证的用户的用户名。
REALM：用于标识发起认证过程的域。
NONCE：由发起认证过程的实体产生的加密因子。
RESPONSE：终端在收到服务器的认证请求后根据服务器端产生的NONCE、用户名密码、URI等信息经过一定的算法生成的字符串。该字符串中包含了经过加密后的用户密码(在认证过程中处理用户密码之外其他信息都会通过SIP消息以明文的方式在终端和服务器端进行传递)。
URI：发起的呼叫请求消息的Request-URI。由于终端在收到认证请求后需要重新向服务器端发起请求（其中带有认证响应信息）。该请求消息在经过网络服务器时某些字段包括Request－URI都有可能被修改。认证头域的URI参数用于传递终端发起请求时原始消息的Request-URI用于对认证信息进行认证，这样才能保证认证过程的正确性。
CNONCE：如果在服务器端超时后终端才向服务器返回了带有认证响应的新的请求消息，则服务器端需要重新产生NONCE重新对用户进行认证。其中NONCE中带有新的NONCE，老的NONCE会通过CNONCE参数返回给终端。
ALGORITHM：用于传递生成RESPONSE的算法。
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
SIP 请求消息：
用于客户端为了激活按特定操作而发给服务器的SIP消息。
INVITE = 发起会话请求，邀请用户加入一个会话，会话描述含于消息体中。
ACK = 证实已收到对于INVITE请求的最终响应。该消息仅和INVITE消息配套使用。
BYE = 结束会话
CANCEL = 取消尚未完成的请求，对于已完成的请求（即已收到最终响应的请求）则没有影响
REGISTER = 注册
OPTION = 查询服务器的能力
SIP响应消息：
用于对请求消息进行响应，指示呼叫的成功或失败状态。
1xx = 通知性应答，如表示正在拨打的180
2xx = 成功应答
3xx = 转接应答
4xx = 呼叫失败
5xx = 服务器失败
6xx = 全局失败
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
(转载自 - 中国IT认证实验室)
SIP-T和BICC的比较
BICC是直接面向电话业务的应用提出的，来自传统的电信阵营，具有更加严谨的体系架构，因此它能为在软交换中实施现有电路交换电话网络中的业务提供很好的透明性。相比之下，SIP的体系架构则不像BICC定义的那样完善，SIP主要用于支持多媒体和其他新型业务，在基于IP网络的多业务应用方面具有更加灵活方便的特性。
BICC是在ISUP基础上发展起来的，在语音业务支持方面比较成熟，能够支持以前窄带所有的语音业务、补充业务和数据业务等，但BICC协议复杂，可扩展性差。在无线3G应用中，BICC协议处于3GPPR4电路域核心网的Nc接口，提供了对(G)MSCServer之间呼叫接续的支持。
在固定网软交换应用中，BICC协议处于分层体系结构中的呼叫控制层，提供了不同软交换之间呼叫接续的支持。采用BICC体系架构时，可以使所有现在的功能保持不变，如号码和路由分析等，仍然使用路由概念。这就意味着网络的管理方式和现有的电路交换网极为相似。
SIP相对而言，在语音业务方面没有BICC成熟，但它能支持较强的多媒体业务，扩展性好，根据不同的应用，可对其进行相应的扩展。在固定网软交换应用中，SIP协议处于扁平体系结构中的呼叫控制层，提供了不同软交换之间呼叫接续的支持。采用SIP体系架构时，从路由角度看，存在两种情况：
第一种情况，正常的ISUP消息添加一些信息后封装在SIP消息中传送，呼叫服务器、号码、路由分析和信令以及业务的互通等功能保持不变，路由分析指引到目标IP地址的寻址。
第二种情况是基于ENUM(IETF的电话号码映射工作组)数据库的。在这种方式下，呼叫服务器的呼叫控制与现有电路交换网中的呼叫控制完全不同，呼叫控制中将没有号码和路由分析，但是仍需业务映射和互通。由于不使用电路识别码CIC、ISUP管理进程、消息传送协议MTP，标准的ISUP协议要相应修改。网络的管理在某种程度上得到了简化(如无须构建信令网，没有路由定义)。另外，和现有网络相比，运营商对网络的控制减少，控制方式发生了巨大的变化。
通过以上分析，采用SIP协议在某种程度上会丢失一些现有电话网络中的功能。要引入这些功能，则需要对SIP协议进行扩展。相比较而言，BICC基本能提供所有现有电话网络的功能。相信，经过修改并标准化的SIP可以达到BICC对传统业务的支撑能力。
SIP-T和SIP-I的比较
关于软交换SIP域和传统PSTN的互通问题目前有两个标准体系，即IETF的SIP-T协议族和ITU-T的SIP-I协议族。
1.IETF的SIP-T协议
SIP-T(SIP for Telephones)由IETFMMUSIC工作组的RFC3372所定义，整个协议族包括RFC3372、RFC2976、RFC3204、RFC3398等。它采用端到端的研究方法建立了SIP与ISUP互通时的三种互通模型，即：呼叫由PSTN用户发起经SIP网络由PSTN用户终结；呼叫由SIP用户发起由PSTN用户终结；呼叫由PSTN用户发起由SIP用户终结。
SIP-T为SIP与ISUP的互通提出了两种方法，即封装和映射，分别由RFC3204和RFC3398所定义。但SIP-T只关注于基本呼叫的互通，对补充业务则基本上没有涉及。
2.ITU-T的SIP-I协议
SIP-I(SIP with Encapsulated ISUP)协议族包括ITU-TSG11工作组的TRQ.2815和Q.1912.5。前者定义了SIP与BICC/ISUP互通时的技术需求，包括互通接口模型、互通单元IWU所应支持的协议能力集、互通接口的安全模型等。后者根据IWU在SIP侧的NNI上所需支持的不同协议能力配置集，详细定义了3GPP SIP与BICC/ISUP的互通、一般情况下SIP与BICC/ISUP的互通、SIP带有ISUP消息封装时(SIP-I)与BICC/ISUP的互通等。
SIP-I协议族重用了许多IETF的标准和草案，内容不仅涵盖了基本呼叫的互通，还包括了BICC/ISUP补充业务的互通。
3.SIP-T与SIP-I的比较
显然，SIP-I协议族的内容远远比SIP-T的内容要丰富。SIP-I协议族不仅包括了基本呼叫的互通，还包括了CLIP、CLIR等补充业务的互通；除了呼叫信令的互通外，还考虑到了资源预留、媒体信息的转换等；既有固网软交换环境下SIP与BICC/ISUP的互通，也有移动3GPPSIP与BICC/ISUP的互通，等等。
尤为重要的是，SIP-I协议族具有ITU-T标准固有的清晰准确和详细具体，可操作性非常强。并且3GPP已经采用Q.1912.5作为IMS与PSTN/PLMN互通的最终标准。所以，软交换SIP域与PSTN的互通应该遵循ITU-T的SIP-I协议族。实际上已经有许多电信运营商最终选择了SIP-I而放弃了SIP-T。基于以上比较和分析，我们可以得出以下结论：
在软交换之间互通协议方面，目前固网中应用较多的是SIP-T，移动应用的是BICC，未来的发展方向是SIP-I；在软交换与媒体网关之间的控制协议方面以及软交换和IAD之间的控制协议方面，MGCP较成熟，但H.248继承了MGCP的所有的优点，有取代MGCP的趋势；软交换与终端之间的控制协议方面，SIP是趋势；软交换与应用服务器之间，SIP是主流，目前此业务接口基本成熟；应用服务器与第三方业务，Parlay是方向，但目前商用不成熟。
(转载)
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
网络电话系统/ IP PBX系统由一个或多个SIP电话以及一个IP PBX服务器组成，还可以选用一个网络电话网关。IP PBX服务器与代理服务器类似：SIP客户端可以是软件电话或者基于硬件的电话，它向IP PBX服务器登记，当其希望进行呼叫时，便向IP PBX请求建立连接。IP PBX具有所有电话/用户的姓名地址录及其相应的SIP地址，因而能够通过网络电话网关或网络电话服务业者提供的VOIP服务来连接内部呼叫或发送外部呼叫。
IP PBX如何在网络上集成并使用PSTN或网际网络来连接呼叫。
VOIP网关是将电话流量转化为数据网络上IP传输的装置。通常用于以下2种方式：
1. 将呼入的PSTN/电话线转化为VOIP/SIP： 通过这种方式，VOIP网关允许常规电话网络接受和发送呼叫。在很多商业案例中倾向于继续使用传统电话线，因为它能保证较高的呼叫音质和可用性。
2. 将传统企业通信交换机/电话系统连接到IP网络：通过这种方式，VOIP网关允许通过VOIP进行呼叫。可以通过VOIP供应商进行呼叫，或者在公司设有多个办事处的情况下，可以通过网际网络发送呼叫来降低内部事务通讯的呼叫费用。VOIP网关也可以作为外部单元或PCI卡使用，在这些装置中大部分都是作为外部单元使用的。VOIP网关将电话线连接到IP网络连接器的一个或多个端口上。
VOIP网关的类型 ：
1. 模拟单元：模拟单元用于将常规模拟电话线连接到网关上。模拟单元能够连接2到24根电话线。
2. 数字单元：数字单元使你能够连接数字线路包括一条或多条BRI ISDN线(欧洲)，一条或多条PRI/E1线(欧洲)，和一条或多条T1线(美国)。
Codec（编/解码器）的作用是将模拟信号转换成数字信号，以便在数据网络上传输。以下是目前正在使用的Codec。
GSM - 13 Kbps (全速), 20毫秒帧尺寸
iLBC - 15Kbps,20毫秒帧尺寸: 13.3 Kbps, 30毫秒帧尺寸
ITU G.711 - 64 Kbps, 基于样本的，也叫alaw/ulaw
ITU G.722 - 48/56/64 Kbps
ITU G.723.1 - 5.3/6.3 Kbps, 30毫秒帧尺寸
ITU G.726 - 16/24/32/40 Kbps
ITU G.728 - 16 Kbps
ITU G.729 - 8 Kbps, 10毫秒帧尺寸
Speex - 2.15 to 44.2 Kbps
LPC10 - 2.5 Kbps
DoD CELP - 4.8 Kbps
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
博文
