H323——460NAT穿透相关

1. 概述
在H323中使用穿透相关的协议为H460.18和H460.19，H323的穿透协议利用了NAT和FW对于出站流量的限制比入站流量限制宽松的特性，从而实现了NAT穿透相关的功能。

2. 信令穿透
信令的NAT穿透的基本原理为当终端设备注册到相关的GK之后，会通过不断发送GRQ或者RRQ消息维持这一和GK之间在NAT/FW上的端口映射关系。建立这一关系之后，信令的流程就可以通过GK下发给终端设备，从而完成各项通话流程。相关的标准文档为H460.18。

在这样的基础上，H323引申出了一个新的概念：traversal server (TS)。TS在概念上是一个具有H460.18的server GK和一个具有H460.18的server proxy组成。

2.1 信令穿透流程
当终端设备支持H460.18时，在GK自动发现模式下，需要在GRQ请求的supportedFeatures字段中携带Signalling Traversal标志，在TS收到这个GRQ请求之后，同样也会在GCF的supportedFeatures字段中携带Signalling Traversal标志，标明自身支持H460.18NAT穿透协议。

同样RRQ和RCF的携带supportedFeatures字段中携带Signalling Traversal标志。需要注意的是在轻量级的RRQ中该信息可能被忽略。（所谓轻量级即指注册保活包）。

当TS明确知道终端和其之间没有NAT，TS可以不使用H460.18协议中的相关规范，同时在相关的RCF中省略supportedFeatures字段下的Signalling Traversal标志，然后所有流程不按照H460.18协议规范进行。

当TS确认需要进行信令穿透时，如果在GRQ或者RRQ的supportedFeatrue字段中携带了Signaling Traversal标记，TS需要忽略在相关请求中携带的地址信息，而是直接使用相关数据包的实际源地址信息作为RAS地址，同时在对应请求的回复中也应该携带相关的标记位，同时还需要在RCF另外携带timeToLive标记位，该标记位的值负责指明RRQ的发送周期，对建立在FW/NAT上的NAT穿透通道进行保活。
##2.2 通话流程
假设存在两个终端EPA和EPB，其中EPA在FW/NAT的内部，EPB在FW/NAT外部。

2.2.1 FW/NAT内部终端外呼流程
当EPA呼叫EPB时：

1). EPA需要通过发送ARQ到TS，从而初始化通话流程，当TS允许通话时，会回复ACF；
2). EPA需要使用ACF中的地址建立H225的TCP通道；
3). EPA发送SETUP消息给TS，TS需要将TS转发给EPB；
4). 来自EPB的任何回复都需要被TS转发给EPA，如果在消息中存在H245的地址，那么TS需要将这个H245地址替换为自身的地址；

实际流程如下所示：

2.2.2 FW/NAT内部终端接收呼叫流程
当EPB呼叫EPA时：

当需要建立和EPA的通话时，TS需要通过发送一条ITU-T H.225.0 SCI RAS信令给内部终端EPA。在这条信息中genericData需要包含IncomingCallIndication字段。
EPA需要针对SCI消息回复SCR，确认该请求已被接受。
EPA在收到这条信令后需要使用SCI信令中地址信息建立一条和TS之间的TCP通道。EPA需要发送FACILITY消息，这条消息的callIdentifier字段需要和之前收到的SCI中IncomingCallIndication的callIdentifier相同。reason字段需要被设置为undefinedReason，conferenceId字段需要被忽略。call reference value需要被设置为0，作为全局call reference。
TS不需要将FACILITY消息转发给任何终端。
TS需要在刚刚建立的TCP通道中发送SETUP消息。
实际流程如下所示：

2.3 建立H245通道
在H225呼叫信令完毕之后，需要建立H245信令的连接通道。
EPA可能在任何时候需要建立H245信令通道，当EPA不知道H245信令通道的地址时，EPA需要向TS发送FACILITY消息，这条消息的reason字段会被设置为startH245，而H245Address字段可能会被忽略。
在TS收到这条FACILITY消息之后，需要回复一条FACILITY消息，在这条回复的消息中reason字段会被设置为startH245，同时会在H245Address中指明相关的地址。这条消息也可以在没有来自EPA的FACILITY消息之前发送。

当EPA建立好和TS之间的H245通道之后，EPA在这条通道中发送的第一条消息应该为H.245 genericIndication，在这条消息中需要设置和H225通道中相同的callIdentifier字段这样做的目的是使TS能够将这条H245消息和具体的通话绑定起来。同时也会携带一个answerCall字段，如果是接听通话，answerCall需要设置为true，其他情况为false。

2.4 信令保活机制
由于FW/NAT的存在，相关的穿越通道需要进行保活，RAS通道使用轻量级的RRQ和RCF进行保活。而H225和H245通道则使用TPKT数据包进行保活。

保活周期一般在5到30秒之间。除非能确保在FW/NAT上的保活周期可以在30秒以上，否则不应该使用大于30秒的值。H225和H245的保活周期和RRQ的发送周期相同。
充当内部网络上非ITU-T H.460.18端点的客户端代理的客户端网关以给定的时间间隔向TS发送这些保持活动状态。 与TS直接通信的ITU-T H.460.18端点必须在给定间隔向TS发送这些保持活动状态。

3. 媒体穿透
媒体数据的发送实际上是双向的。但是由于FW/NAT的存在，来自外部的数据包不能转发给内部的终端，这样就形成了单通的媒体通道，为了解决外部的数据包发送给内部终端的问题，协议定义了一个keep-alive channel，在这个通道中，内部的终端会向一个外部的地址发送保活包，从而完成内部地址到外部地址的的映射关系建立的流程。

H460.19还定义了多路媒体复用的相关逻辑，这一特性在NAT/FW穿透时可以有效减少穿透所需建立的地址映射关系，设备仅需维护一个地址映射

##3.1 媒体穿透流程
为了标明设备支持H460.19能力，需要在外呼的SETUP信令和接收呼叫时发送的CALL PROCEEDING，ALERTING，CONNECT信令的support featrue字段中携带mediaNATFWTraversal标记位。并且需要将FACILITY信令的facilityReason字段置为forwardedElement。

支持多路媒体复用的设备需要一直在信令的support featrue字段中携带supportTransmitMultiplexedMedia标志。支持多路媒体复用的服务器需要在信令的support featrue字段中携带mediaTraversalServer标志。
在服务器发送的OLC信令中，需要在Traversal Parameters中携带keepAliveChannel字段，表明相关的保活字段，并且申明自身的保活通道IP和端口。在客户端收到这个保活通道地址之后，客户端会想这个地址周期性地发送报活包，从而在FW/NAT上形成相关的NAT穿透通道。在服务器接收到相关的报活包之后，服务器会向保活包的来源地址发送相关的媒体数据包，从而实现媒体的NAT穿透。

下面是关于保活通道和实际媒体通道的发送接收示意表：

————————————————
版权声明：本文为CSDN博主「大风起兮呵呵呵」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_32648921/article/details/116225119