SIP协议（二）

语音编码，语音帧，会议室

（1）语音编码，语音帧

（2）补充会议室的抓包

语音编码

现主要有的语音编码有:
G.711, G.723, G.726 , G.729, ILBC，QCELP, EVRC, AMR, SMV
各种编解码都有其应用的重点领域。
ITU 推出G.7XX系列的语音编码,目前广泛应用的有：G.711，G.723,G.726, G.729
在通话过程中语言编码协商主要是通过SDP的offer/answer模型来进行的，在SIP的体现则是invite和200 OK包。以200 OK包中SDP携带的语音编码为双方协商后的语音编码，RTP采用该编码进行传输。

页面相关参数：

编码协商优先级有两种方式（主叫和被叫）默认为被叫；此参数是将本话机作为被叫时进行编码协商使用什么编码的优先级。
1.、当该选项设置为"被叫"时，话机根据自身设置的语音编码顺序进行协商。

编码协商优先级有两种方式（主叫和被叫），默认为被叫，即本话机作为被叫时，根据自身设置的语音编码顺序进行协商，
设置B话机语音编码优先级为：PCMA->G722->PCMU。
A话机语音编码优先级为：PCMU->PCMA->G722，
B话机拨打A（A为待测）话机：
由下图可知，Invite包中SDP携带的语音编码是话机B中的顺序：
PCMA->G722->PCMU

200 OK包中SDP携带的语音编码是待测话机A中的顺序：
PCMU->PCMA->G722；
此时的待测设备A的语音编码优先级设置为：被叫，则协商结果使用的是话机本身所设置的语音编码顺序（200 OK包）进行语音编码协商，则RTP以PCMU编码进行发送语音包。

 

2、当该选项设置为"主叫"时，话机根据收到的invite 包中的语音编码顺序进行协商。

和1中的设备和环境相同的情况下，仍为B拨打A：
B发送的invite包中的SDP顺序为：PCMA->G722->PCMU>G729

 

A发送的200 OK包中的语音编码顺序与B发送的invite为准，其中A不支持的语音编码则不显示。最终该路通话以PCMA进行发送RTP流。

3、200 OK SDP中首位匹配编码选项：

启用该项的时候，200 OK SDP中仅会显示首位的SDP语音编码，其他的编码则不会显示：

（1）、在UCM上进行呼叫时，设备双方均分别与UCM进行协商，协商成功后才能进行通话；
（2）、协商的语音编码通常来说为双方均支持的语音编码，如果双方没有共同的语音编码情况下，如果有一方含有PCMU则使用默认的PCMU进行通话；如果双方没有共同语音编码，连PCMU也没有的情况下，则不能进行通话，会有488应答。

语音帧

语音帧是用于设置单包发送的语音帧的数量（建议基于以太网数据包的IS限制最大值为1500个字节）设置该值时，要注意请求数据包时间（ptime,在SDP数据报中）是配置该参数的结果

设置话机A 的语音帧为1，查看话机发出的请求的SDP数据包

会议室

先添加一个会议室6302，然后邀请成员
进入会议室有两种方法，（1）在web界面邀请，输入分机号码，（2）分机拨通6302,

DTMF，语音留言，DND，TCP的SIP

DTMF

DTMF（dual-tone multifrequency）：多音双频，由4个高频群和4个低频群组成。一个高频信号和一个低频信号叠加组成一个组合信号，代表一个数字。DTMF信号有16个编码。

作用：可以作为实现电话号码快速可靠传输的一种技术，它具有很强的抗干扰能力和较高的传输速度，因此可广泛应用在电话通信系统上。

VOIP中的传送DTMF信号的三种方式：
通过通信协议传输（SIP信令）【带外检测方式】
通过RTP的数据内容传输（In Band）【带内检测】
通过rfc2833的规则和格式包传输【带内检测】

详解传送DTMF信号的三种方式

（1）通过通信协议传输（SIP信令）【带外检测方式】
通过SIP信令的INFO方法携带DTMF信号。通过SIP INFO包中的signal字段识别DTMF按键。注意当DTMF为"*"时不同的标准实现对应的signal=*或signal=10
好处：不会影响到RTP数据包的传输
不足：由于SIP控制信令和媒体传输（RTP）是分开传输的，很容易造成DTMF信号和媒体包不同步

抓包SIP INFO
话机A设置DTMF为SIP INFO

A拨给B，A在通话中按1和0（A本身的听筒，耳机，扬声器可以清晰的听到按键声），查看INFO数据包的Message Body项的Signal字段为1跟0

（2）通过RTP的数据内容传输（In Band）【带内检测】
In audio是指直接将DTMF的音频数字信号不经任何处理直接打成RTP包在IP网中传输。其中可能和用户的语音媒体流混合在一起传输。程序要获知哪个包有DTMF信号，是什么DTMF信号，必须提取RTP数据包进行频谱分析，经过频谱分析得到高频和低频的频率，然后查表得到对应的按键。

抓包分析In audio
A设置DTMF方式为In audio方式，A呼叫B（A按三次键，AB双方均能听到清晰的按键声）
在invite和200 ok包中并没有看到相关的DTMF信息

选择A发送的RTP查看，可以看到RTP均匀的发送DTMF事件。

（3）通过rfc2833的规则和格式包传输【带内检测】
通过RTP传输，由特殊的rtpPayloadType即TeleponeEvent来标示RFC2833数据包。同一个DTMF按键通常会对应多个RTP包，这些RTP数据包的时间戳均相同，此可以作为识别同一个按键的判断依据，最后一包RTP数据包的end标志置1表示DTMF数据结束。

抓包rfc2833
话机A设置DTMF为rfd2833

A拨给B，A在通话中按8（A本身的听筒，耳机，扬声器可以清晰的听到按键声）

Payload type:telephone-event（101）是DTMF的有效载荷值
Timestamp：同一事件的时间戳值是一致的；接收方可以通过判断时间戳来剔除冗余信息。
Event ID:显示按键值

RTP数据包的end标志置1表示DTMF数据结束。

RFC2833模式下，一般DTMF发送有误可能的情况有：A）Marker值标记错误；B）Timestamp时间戳重叠；C）Event Duration混乱

DTMF方式组合情况：

（1）In audio +RFC2833
A呼叫B，A按键，B听不到按键音，查看invite和200 OK的SDP能看到RFC2833的有效载荷类型
（2）In audio+SIP INFO
A呼叫B，A按键，B均能听到清晰的按键声，查看invite和200 OK的SDP看不到RFC2833的有效载荷类型，查看SIP包能看到INFO包，查看RTP的播放情况，能看到均匀发送DTMF事件。
（3）RFC2833+SIP INFO
A 呼叫B，A按键，B不能听到按键声，查看invite和200 OK的SDP，能看到RFC2833的有效载荷类型，能查看到INFO 包，和RTP里有event事件包。
（4）IN audio+RFC2833+SIP INFO
A呼叫B，A按键，B 不能听到按键声，查看invite和200 OK的SDP，能看到RFC2833的有效载荷类型，能查看到INFO包，RTP能看到event事件，RTP播放情况，能看到均匀的发送DTMF事件。

DTMF的有效载荷值——默认为101，此值可以修改，取值范围为：96~127之间，修改此payload值后，在wireshark上如果不修改相对应的payload值，是无法查看到event事件的信息。

语音留言信箱

语音信箱（voice mail）用于接收遇忙或者无接听情况下的语音留言而产生的电子邮件
开启待测话机所用UCM服务器号码的语音信箱功能

查看语音信箱接入号（想听信箱直接拨语音信箱接入号）

设置待测话机的语音信箱接入号

启用MWI功能

抓包分析

查看SUBSCRIBE包中有
Event：Voice Mail事件类型必须为Message-summary；
Accept：可接受的描述格式。

NOTIFY包中，
Event：类型为Message-summary，说明是一条Voice Mail更新通知；
Message-Waiting：无留言为“no”，有留言为“yes”；
Voice-Message：0/0，前者为新留言数，后者为旧留言数。

DND

DND同步：开启免打扰模式，完全屏蔽来电，不同的是，来电Invite由谁回复。
本地DND：开启DND来电后依然会收到Invite，用户可选择是否有DND来电提示音，之后话机会自动拒接来电，并携带头域为"Warning: 399 GS “Do-not-disturb is on”"。
服务器DND：基于UCM远程同步DND，开启/关闭DND后会自动拨打一个*功能告诉服务器话机需要开启/关闭DND，来电后(开启DND)不会和收到Invite，服务器自动拦截Invite并处理。
.DND和遇忙转移并存时，遇忙转移优先级高

本地DND验证抓包：
开启本地DND，用话机A拨打待测话机。

DND同步-服务器
首先进入UCM服务器地址，查看DND业务码

其次到话机web页面设置好业务码

待测话机拨打*77开启免打扰，抓包

用辅助机拨打给待测话机，抓包
（辅助话机拨打待测话机时，待测话机直接提示对方在通话中，待测话机并未收到Invite，服务器自动把该号码标记为免打扰了。由此可见，本地DND，话机会收到Invite，然后做出处理，而服务器DND，则服务器会自动处理DND。）

TCP的SIP

SIP协议通常都是用UDP传输，而这里也可以用TCP来实现，做个对比，首先是毫无设置的话机A拨通话机B：

使用的是UDP作为传输协议；
其次在UCM服务器上查看TCP所用端口

修改话机传输协议与SIP服务器端口号

话机A拨通话机B，抓包分析，这样就实现了用TCP作为传输层协议的SIP

SRTP，Session Time处理流程，

SRTP

SRTP，即安全实时传输协议(Secure Real-time Transport Protocol)，其是在实时传输协议(Real-time Transport Protocol)基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。
由于实时传输协议和可以被用来控制实时传输协议的会话的实时传输控制协议(RTP Control Protocol)有着紧密的联系，安全实时传输协议同样也有一个伴生协议，它被称为安全实时传输控制协议(Secure RTCP或SRTCP)；安全实时传输控制协议为实时传输控制协议提供类似的与安全有关的特性

加密方式：加密算法有两种加密模式，它们能将原始的AES块密文转换成流密文：分段整型计数器模式和f8模式。 除了AES加密算法，安全实时传输协议还允许彻底禁用加密，此时使用的是所谓的"零加密算法"。零加密算法并不进行任何加密，也就是说，加密算法把**流想像成只包含"0"的流，并原封不动地将输入流复制到输出流。这种模式是所有与安全实时传输协议兼容的系统都必须实现的。

为了进行消息认证并保护消息的完整性，安全实时传输协议使用了HMAC-SHA1算法。这种算法使用的是默认160位长度的HMAC-SHA1认证**。但是它不能抵御重放攻击；重放保护方法建议接收方维护好先前接收到的消息的索引，将它们与每个新接收到的消息进行比对，并只接收那些过去没有被播放过的新消息。

SRTP的协商：

协商一般以主叫方为主：
（1）主叫不启用SRTP，被叫不启用/启用但不强制都是不加密方式进行通话；
（2）主叫不启用SRTP，被叫使用允许且强制时，禁止呼叫，会接收到一个488的不接受应答；
（3）主叫开启SRTP但不强制，被叫为不启用/允许但不强制/允许且强制时，均使用加密方式；
（4）主叫开启SRTP且强制，被叫为不启用/允许但不强制/允许且强制时，均使用加密方式。
（5）加密方式协商不成功也会提示488不接受的应答，如服务器只支持AES 128 bit的加密方式，而设备采用AES 256 bit加密方式，则无法成功呼叫。

UDP注册模式下

Invite包的SDP携带信息SRTP信息：

200 OK包中的SDP携带SRTP信息：

当使用TLS方式注册
wireshark在未解密的情况下是抓不到相关的SIP包的，而且互发语音包时，TLS一方并不是采用SRTP协议发送语音包，而是采用RTP转码的形式，直接将RTP设置为加密模式。如下图：

因为该话机采用的是TLS注册方式，所以A所发的包为加密的包，wireshark没有解密就抓不到SIP包，现在抓到的包为B和UCM的SIP流程发包情况，但是在RTP流中，我们可以看到A（192.168.79.14）和UCM之间发送的包为RTP形式，而并非SRTP。那我们怎么判断该RTP是加密了的呢？那么我们就要看RTP包里的字段payload值了。通常情况下，正常的RTP包的payload值呈现出来的是一串比较规整的随机数，如图所示：

Session Time处理流程

Session Timer的功能：就是在通话过程中通过re-INVITE和UPDATE方法进行周期性的会话刷新，以判断通话两端是否存活。（A打给B，B挂断，A不知道B已经挂断，在这个模式下通过接受或者发送re-Invite和update的方法得知B已经挂断）

Session Timer主要引入两个参数：会话超时时间，最小超时时间

（1） 会话超时表示会话超时时间，当已经协商确定会话超时值，那么该会话将在（会话超时/2）的时间用re-INVITE或者UPDATE的请求进行会话更新。一旦通话时间间隔= 会话超时时间，还没有通过UPDATE或 re-INVITE信息没有刷新，则通话自动结束。
（2） 最小超时表示会话间隔的最小值，以秒为单位。当它被用在INVITE或UPDATE请求中时，用来表示该会话所要使用的会话间隔的最小值。当它出现在请求或响应中，它的值不能小于90秒。如果这个头字段没有被指定，就取它的缺省值90秒。
（3）UAC指定刷新对象：主动拨打电话时，在Invite中携带会话超时和最小超时头域，并读取"UAC指定刷新对象"的值，如果是Omit则不带refresher头域，让被叫指定会话更新方，如果是UAS/UAC，则携带refresher=UAS/UAC，主叫指定会话更新方。
SIP通信中，在一个事务中，UAC（User Agent Client）用于发起请求，UAS（User Agent Server）用于接收请求。
（4）UAS指定刷新对象：被叫接听电话时，查看来电Invite 是否存在refresher，如果没有，则读取"UAS指定刷新对象"的值，携带在回复的200 ok中，如果有，则直接使用该值，携带在回复的200 ok中。
（5）UPDATE和re-INVITE方法 会话更新默认使用UPDATA方法进行刷新；如果需要使用INVITE方法进行会话更新，可以登录话机A的WEB，在账号的SIP设置界面，勾选"强制INVITE"，那么在后面的通话中，话机A作为刷新者进行会话刷新时，会使用INVITE方法而不是UPDATE;

会话刷新者的协商

话机上开启会话超时，表示该话机支持Session Timer，需要请求Session Timer功能协商，需要在话机web页面勾选主叫请求计时（话机作为主叫时，在发送的INVITE中携带SessionTimer参数，请求会话刷新）或者勾选被叫请求计时（话机作为被叫时，在主叫未请求会话刷新的情况下，会在200OK中携带SessionTimer参数，请求会话刷新）。 而在通话中，由哪一方发送UPDATE和re-INVITE方法进行周期性的会话刷新，主要是通过会话建立的SIP信令协商。

UAC指定刷新对象

（1）话机A配置如下：

（2）话机A向话机B发送INVITE请求,在发送的INVITE方法中的Supported头域中加入timer标签，并携带Session-Expire和Min-SE和refresher；

（3）话机B收到A的INVITE后，检查话机A的Session-Expires值比自己的Min-SE值大，就在响应的200OK中写入话机A的Session-Expires值，且话机A的INVITE中有携带refresher=uac，此时B会忽略自己的"UAS指定刷新对象"选项值，而在200OK中写入话机A的refresher值，如下图：

（4）Session Timer协商Session-Expires=180，refresher=UAC，所以在接下来的通话中，话机A每隔Session-Expires/2长的时间发送UPDATE进行会话刷新

（5）在通话中，如果话机B网络出现问题，话机A发送UPDATE后一直没有收到话机B响应的200 OK，在时间间隔了3/4 Session-Expires时，就发送bye请求拆断与话机B的通话

UAC没有指定刷新对象

（1）话机A配置如下：

（2）话机A向话机B发送INVITE请求,在发送的INVITE方法中的Supported头域中加入timer标签,并携带Session-Expire和Min-SE。由于话机A没有指定刷新对象，所以INVITE中没有携带refresher；

（3）话机B收到A的INVITE后，检查话机A的Session-Expire值比自己的Min-SE值大，就在响应的200OK中写入话机A的Session-Expires值，话机A的INVITE中没有携带refresher，所以话机B在200OK中写入自己的"UAS指定刷新对象"选项的值refresher=UAS，如下图：

（4）Session Timer协商的最后结果为Session-Expires=180，refresher=UAS，所以在接下来的通话中，话机B每隔Session-Expires/2长的时间发送UPDATE进行会话刷新；从数据包中可以看到，此时话机B发送的UPDATE中，携带的refresher=UAC，因为此时是话机B向话机A发送UPDATE，在这个过程中话机B是请求发起者UAC，话机A是请求的接收者UAS，而在200 OK中协商的refresher是话机B，所以B发送UPDATE时，refresher=UAC。

5）在上一个例子中提到，发送的UPDATE一直没有收到200 OK响应时，在时间间隔了3/4 Session-Expires时会自动拆断通话。还有一种情况，话机也会自动拆断通话。如：话机B网络断开，导致话机A在规定的周期时间(Session-Expires/2)里没有收到话机B发送的会话刷新UPDATE，话机A就可以判断话机B已经不在通话中，在3/4的Session-Expires时间发送bye请求拆断与话机B的通话，话机A退出通话界面。

422回应代码

422响应代码出现在会话协商过程中，当Session-Expires的间隔太小（小于UAS所支持的Min-SE头字段的值）时，UAS返回422代码要求UAC重新协商Session-Expires，UAC将422返回的Min-SE的值写入INVITE包含的Session-Expires字段，重新发送INVITE给UAS，请求会话刷新。
（1）话机A的配置如下：

（2）话机B的配置如下：

（3）话机A呼叫话机B，话机B收到A的INVITE后，检查到话机A的Session-Expiresr值180比自己的Min-SE值270小，不能接受，就响应422 Session Interval Too Small给话机A，并在422中写入自己能接受的Session-Expires值和Min-SE值
（4）话机A收到422响应后，会将422中携带的Session-Expires值和Min-SE写入INVITE中重新发给话机B，这样A请求Session-Expires值就在B可接受的范围，B响应200OK，与A成功协商建立通话

 

DNS的三种模式，NAT穿透

DNS的三种模式

DNS SRV

SRV：服务记录，用于为给定域指示各种服务的位置。
使用SRV记录可以避免在SIP服务器出现问题后，话机不能注册的。话机使用DNS SRV的方式进行注册时，通过SRV记录可以得到SIP服务器的IP地址和端口，选择优先级较高的服务器发送注册请求，如果该服务器网络出现问题或者该服务器不可用，那话机就可以自动向下一个服务器的IP地址发送请求

·配置DNS服务器

测试网远程到10.154.0.2（公网远程到192.168.90.2），新建一个正向查找区域，下一步，输入要设置的域名，如sipsrv-xfh.com，下一步到完成；
（1） 新建A记录：
A记录提供了标准的主机域名与IP地址的映射关系；
右击sipsrv-xfh.com，新建主机，填写主机与IP地址，（我们要使用SRV，所以这里创建三个有前缀的A记录）如：主机为xiao1，IP为192.168.80.21，这时域名sipsrv-xfh.com下会创建一个子域名xiao1.sipsrv-xfh.com，对应IP地址为192.168.80.21；
然后我们再创建三个子域名xiao2.sipsrv-xfh.com、xiao3.sipsrv-xfh.com、xiao4.sipsrv-xfh.com，分别对应一个能Ping通但是不提供sipserver的IP和一个不能ping通的IP，及最后一个与xiao1相同的IP：（设置优先级比正确的UCM服务器IP前的错误IP地址会影响拨通话机的时间，它需要一个一个查询到正确的IP，就这个例子而言拨通时间需要7-8s，将其他三个没用的子域名去掉则可以恢复正常）

（2）新建SRV记录
右键sipsrv-xfh.com,选择其他记录，选择服务位置（SRV）创建记录

我们可以看到SRV记录的格式中包含域、服务、协议、优先级、权数、端口号、目标主机。而该记录的意思是服务器xiao1.sipsrv-xfh.com在sipsrv-xfh.com域中提供SIP服务，此服务基于UDP协议，端口为5060（sip4中设的是5066）；
优先权Priority：给出处理的顺序，按照priority从小到大的顺序对记录搜索，搜索到匹配的记录后，就停止搜索priority值更大的记录，对于拥有相同priority的记录将通过weight再次选择；
权重 Weight ：对于拥有相同priority的多条记录，weight给出了选择某条记录的几率，值越大，被选中的概率就越大，合理的取值范围为0-65535；
然后创建三个基于UDP的SRV记录，名称与A记录中名称一致（优先级和权重可重新调整）：

顺便再创建TCP和TLS（sips）的SRV（注意端口须与sip server对应）：

（3）话机SRV设置
将设备的DNS服务器地址指向刚才配置的server

登录web，在注册SIP账号页面中，SIP服务器地址填域名sipsrv-xfh.com，DNS模式选择为SRV：

（4）SIP SRV注册流程：
设备注册时，先发送DNS Standard query SRV查询，请求地址为_sip._udp.sipsrv-xfh.com，表示需要查询该域中支持UDP协议的SIP服务器的SRV记录；

DNS服务器收到请求后进行回复，包含该域中关于SIP服务的SRV记录，记录中包含SIP服务的端口和最新域名，以及优先级、权重等详细信息，如下图：

由于DNS Server回复的Answers中的target仍然是域名，所以话机会根据SRV记录中的priority优先级值和weight权重值进一发送DNS A记录进行查询；
先对比priority，值越小优先级越高；如果priority相同则对比weight，值越大被选中概率越高；如下图：

DNS NAPTR

使用NAPTR模式，那通过DNS NDPTR查询后得到向该服务器注册时需要使用的SIP传输协议为TCP，话机这时无论选择的SIP传输协议是UDP/TCP/TLS都自动会切换到TCP，从而成功注册。NAPTR的解析流程中包含了SRV记录，相对于SRV记录，其主要是对网络传输协议进行要求；
DNS NAPTR资源记录的功能是能够将原来的域名映射成一个新的域名或者URI(Uniform Resource Identifier)，并通过flag域来指定这些新域名或URI在后继操作中的使用方法；
（1）配置DNS服务器
远程到10.154.0.2，新创建一个域，名称为sipnaptr-xfh.com；
新建NAPTR记录：

Order：顺序，类似优先级，按照order从小到大的顺序对记录搜索，匹配到记录后就停止搜索order更大的记录；
Preference：对应windows DNS server中的首选项，在order相同情况下对比该值，值越小偏好越高；
Flags：标记字符串，为[A-Z0-9]中的一个字符，表达映射关系及记录本身的含义，目前有"U",“S”,"A"和"P"四个标志：
"A"表示下一步进行A，AAAA或者A6查询；
"U"表示下一步不需要DNS查询，本次输出的是满足RFC2396要求的absoluteURI；
"S"表示下一步进行SRV查询；
“P"表示由用户根据service定义自己的规则，所以既可以是终结标志，也可以是非终结标志：
其中"U”,"S"和"A"是终结标志，即下一步不需要再进行NAPTR查询，如果flags为空(即什么字符也没有)，表示用户需要根据本次输出，再进行一次NAPTR查询；
依次创建三条记录，对应UDP/TCP/TLS（优先级后期可按照用例需要修改）：

（2）话机配置
首先依旧需要确定话机的DNS服务器地址指向刚才配置的server；
SIP服务器需要填刚才配置的支持NAPTR的域名：sipnaptr-xfh.com：

（3）SIP NAPTR注册流程
NATPR完成数据包流程如下图：

先进行DNS Standard query NAPTR请求：

DNS服务器响应NAPTR:

Order最高的是99，对应域名为_sip._tcp.sipsrv-xfh.com；
flags为S，下一步进行SRV查询，流程与上面写的SRV一致；
service为SIP+D2T，表示话机将在新目标地址上使用TCP作为传输层协议请求SIP服务， 即使WEB上配置的协议是UDP；

NAT穿透

NAT穿透技术出现的原因：使用NAT技术的弊端（各种应用不断，其协议应用也各有不同，有的根本无法通过NAT）

NAT三种实现方式：

（1）静态地址转换：一个公网IP对应一个内部IP,一对一转换；
（2）动态地址转换：N个公网IP对应M个内部Ip,不固定的一对一IP转换关系．同一时间，有M-N个主机无法联网；
（3）端口多路复用：对外只有一个公网IP,通过端口来区别不同内部IP主机的数据；

NAT穿透技术的原理：

假设有两台分别处于各自的私有网络中的主机：A和B；N1和N2是两个NAT设备；S是一个使用了一个众所周知的、从全球任何地方都能访问得到的IP地址的公共服务器
步骤一：A和B分别和S建立UDP连接；NAT设备N1和N2创建UDP转换状态并分配临时的外部端口号
步骤二：S将这些端口号传回A和B
步骤三：A和B通过转换好的端口直接联系到对方的NAT设备；NAT设备则利用先前创建的转换状态将分组发往A和B

NAT穿透技术的应用：

（1）利用nat123端口映射及穿透的强大功能，可以在局域网内服务器（个人电脑）上顺利发布网站，实现外网内网轻松访问和管理,80穿透不限速。
（2）UDP打洞技术：打洞主要采用的是udp的无面向连接的特性来实现，同过user1连接server，打通user1的对外ip和端口，通过user2连接server，打通uer2对外的ip和端口，然后user1和user2通过彼此已经打通的对外ip和端口实现通讯

NAT类型

1）Full Cone NAT（完全锥形MAT）：设备比较少的情况下，内网主机端口在NAT网关完成端口映射后，外网的主机可以通过这个映射好的端口进行访问
2）Restricted Cone NAT (限制雏形NAT):相比较于全锥形，在完成端口映射之后，对于和外网的IP地址通信有限制，只有内网对外访问过的ip地址才可以对该端口进行通信
3）Port Restricted Cone NAT(端口限制雏形NAT) ：相比较于限制锥形NAT，在端口上也加以限制，只有内网主机和外网的IP+端口通信过才能进行通信
4）Symmetric NAT (对称NAT) ：同一个内网主机，跟不同的外网ip+端口进行通信时，在NAT表上会映射成不同的端口号

了解穿透原理，STUN,keep-alive,v*n穿透

STUN穿透，keep-alive

STUN穿透：是处于NAT后方的客户端向STUN发送一个UDP数据包，当UDP报文穿过NAT后达到STUN时，STUN获得其数据经过NAT后最终使用的IP地址和端口，并将获得的IP和端口写入到响应数据包中，然后返回给客户端，客户端通过对比自身和STUN返回的IP和端口，从而确定自身是否处于NAT后方，当客户端处于NAT后时，客户端在需要穿透的数据中携带NAT最外层IP、端口，方便NAT外的设备能通过这个IP、端口向内发送数据，从而实现穿透。

话机启用STUN穿透后，SIP通讯过程中，SIP注册和SDP媒体协商前，均以即将使用的端口为源端口，并与STUN进行交互，从而获得对应的NAT外网端口和IP，然后再将获得的外网IP和Port携带到注册包（Via、Contact）或SDP中，以便注册服务器能找到话机，从而实现UDP穿透，实际上穿透是一个临时端口映射过程，NAT发现一个连接超过一段时间后没有活动，它会关闭这个映射，因此话机必须每隔一段时间发送一个UDP包，源端口为话机自身需要监听的端口，从而保持NAT上的指定端口不被关闭，即Keep alive机制。

NAT类型检测

环境搭建：
根据NAT的工作原理，NAT类型检测时，STUN Server必须绑定有两个不同Server IP地址，如局域网中的STUN Server（192.168.83.243/244），因STUN仅能检测最外层NAT类型的特点，建议使用局域网内部构建实验环境，在办公网络中连接一台Router，WAN口连接公司网络，LAN口开启DHCP，并连接Phone
话机配置：
1）WEB→电话设置→基本设置→STUN服务器（192.168.83.243）。
2）注册为分机号1105，设置NAT检测为STUN
3）重启话机，抓取数据并过滤"classicstun"。

NAT类型检测案例分析

使用局域中的STUN Server 192.168.83.243
以Port Restricted Cone NAT/Full Cone检测分析具体数据交互过程：
Port Restricted Cone NAT（端口限制圆锥形NAT）
1）参考下图，话机IP106使用源端口14863向STUN243发起UDP请求，由STUN243响应Response，携带MAPPED-ADDRESS（包含话机经过NAT后的IP、Port）、CHANGED-ADDRESS（包含另一个STUN地址244）字段，话机源地址与MAPPED-ADDRESS中的地址不同，说明话机处于NAT后方，继续检测，反之停止检测。

（2）话机源端口不变，继续使用14863端口向STUN243发送UDP请求，要求STUN243 Change IP和Port（即以STUN244）响应请求，连续三次尝试均未收到来自STUN244响应的数据包，说明NAT属于受限型，继续检测，反之为Full Cone，停止检测（受限型，继续检测）。

（3）话机源端口不变，继续使用14863端口向STUN244发送UDP请求，要求STUN244返回话机IP、Port，此时将STUN244返回的Port与（1）步骤中STUN243返回的Port进行对比，Port相同，说明NAT不属于对称型，需继续检测，反之属于对称型，停止检测（port改变，不对称型，继续检测）。

（4）话机源端口不变，继续使用14863端口向STUN243发送UDP请求，要求STUN243 IP不变，换一个端口响应话机，出现三次连续无响应，说明IP不变，Port变更后无法向NAT后方的话机发送数据，即Port Restricted Cone NAT，反之Restricted Cone NAT（IP受限）。

（5）话机NAT类型显示（warning头域显示：port Restricted Cone NAT）

以SIP注册过程分析数据穿透过程。

（1）使用话机位于NAT后方，且需要使用5060进行SIP注册，在SIP注册前，应先以5060为源端口，向STUN发送UDP请求，要求返回该UDP经过NAT后的外网IP和Port。

（2）由STUN响应请求，在MAPPED-ADDRESS中携带话机外网IP、Port，该外网IP、Port与话机产生对应的临时映射关系。

（3）话机使用STUN返回的外网IP、Port，替代至Register中的VIA、Contact头域，例如，话机（192.168.1.106）Register中使用STUN返回的IP（192.168.79.9）、Port（5060）。

SIP SDP
话机启用STUN穿透后，在呼叫发起或接收前，均以即将使用的媒体端口为源端口，并与STUN进行交互，从而将获得对应的外网Port、IP携带到SDP中，通常涉及到媒体端口有Audio、Video、RTCP、BFCP、FEC、FECC等
以音频呼叫为例分析数据穿透过程。
（1）例如，GXP2200发起通话，默认情况下会使用Audio RTP端口5004和RTCP端口5005，在发送INVITE前，话机应分别使用5004、5005为源端口，与STUN进行交互，从而获得对应的外网IP、Port。
（实际操作里使用的不是5004,5005，而是38371）

（2）发起INVITE时，将获得的外网IP、Port分别携带到SDP对应媒体属性中，例如，话机（192.168.1.60）SDP中使用的外网IP（192.168.79.9）、Port

v*n

Openv*n 是一个基于 OpenSSL 库的应用层 v*n 实现。和传统 v*n 相比，它的优点是简单易用。
Openv*n允许参与建立v*n的单点使用共享金钥，电子证书，或者用户名/密码来进行身份验证。它大量使用了OpenSSL加密库中的SSLv3/TLSv1 协议函式库。Openv*n能在Solaris、Linux、OpenBSD、FreeBSD、NetBSD、Mac OS X与Windows 2000/XP/Vista上运行，并包含了许多安全性的功能。它并不是一个基于Web的v*n软件，也不与IPsec及其他v*n软件包兼容。
原理
Openv*n的技术核心是虚拟网卡，其次是SSL协议实现，由于SSL协议在其它的词条中介绍的比较清楚了，这里重点对虚拟网卡及其在Openv*n的中的工作机理进行介绍:
虚拟网卡是使用网络底层编程技术实现的一个驱动软件，安装后在主机上多出现一个网卡，可以像其它网卡一样进行配置。服务程序可以在应用层打开虚拟网卡，如果应用软件(如IE)向虚拟网卡发送数据，则服务程序可以读取到该数据，如果服务程序写合适的数据到虚拟网卡，应用软件也可以接收得到。虚拟网卡在很多的操作系统下都有相应的实现，这也是Openv*n能够跨平台一个很重要的理由。
在Openv*n中，如果用户访问一个远程的虚拟地址(属于虚拟网卡配用的地址系列，区别于真实地址)，则操作系统会通过路由机制将数据包(TUN模式)或数据帧(TAP模式)发送到虚拟网卡上，服务程序接收该数据并进行相应的处理后，通过SOCKET从外网上发送出去，远程服务程序通过SOCKET从外网上接收数据，并进行相应的处理后，发送给虚拟网卡，则应用软件可以接收到，完成了一个单向传输的过程，反之亦然。