https://blog.csdn.net/vincent1941/article/details/2119996?%3E
簡(jiǎn)介
????? H.460.18的全稱是H.323信令穿越NAT和防火墻，它是國(guó)際電聯(lián)(ITU-T)制定的H.323系統(tǒng)中信令穿越NAT和防火墻的標(biāo)準(zhǔn)，與之密切相關(guān)的協(xié)議是H.248.19，它媒體穿越NAT和防火墻的標(biāo)準(zhǔn)方法。它有以下兩個(gè)特點(diǎn)：
1) 它基于Client-Server模型，并不是p2p穿NAT和防火墻的方法（如IETF的ICE）
2) 沒有進(jìn)行NAT類型檢查(不能實(shí)現(xiàn)p2p的RTP碼流傳輸，具有有限的擴(kuò)展性)
基本原理
????? 內(nèi)網(wǎng)終端呼叫外網(wǎng)終端的流程與正常的H.323呼叫過程一樣。當(dāng)外網(wǎng)終端呼叫內(nèi)網(wǎng)終端時(shí)候，呼叫被尋址到TS (Traversal Server) 的外網(wǎng)IP。TS使用一條RAS消息，請(qǐng)求內(nèi)網(wǎng)終端向TS建立H.225.0通道。
外網(wǎng)終端呼叫內(nèi)網(wǎng)終端的H.225.0呼叫流程
1) 為了建立TS到內(nèi)網(wǎng)終端EPA的呼叫，TS發(fā)送一條H.225.0 SCI RAS消息給EPA, SCI包含一個(gè)IncoimgCallIndication的genericData字段；
2) EPA收到SCI消息，回應(yīng)一條SCR響應(yīng)消息給TS；
3) EPA根據(jù)IncoimgCallIndication中的callSigallingAddress字段規(guī)定的地址建立一個(gè)TCP連接，然后發(fā)送一條H.225.0 FACILITY消息，攜帶有callIdentifier字段（根據(jù)前面收到的IncoimgCallIndication的callIdentifier字段設(shè)置）；
4) TS收到FACILITY消息（注意不要轉(zhuǎn)發(fā)該消息），根據(jù)FACILITY消息中的callIdentifier確定這個(gè)呼叫與TCP連接的關(guān)聯(lián)；
5) 在剛建立的H.225.0 TCP連接上，TS發(fā)送一個(gè)H.225.0 SETUP消息，后面的過程就與正常的呼叫流程一樣了。
H.245連接建立
1) EPA收到來自TS消息中含有H245Address字段后，根據(jù)這個(gè)地址向TS建立H.245通道。若EPA在要建立H.245通道時(shí)，還沒有收到H245Address字段，EPA主動(dòng)向TS發(fā)一條FACILITY消息，它包含設(shè)置為startH245的reason字段。TS收到FACILITY消息，回應(yīng)一個(gè)FACILITY消息，并攜帶H245Address字段。
2) 當(dāng)EPA與TS建立H.245通道后，EPA在通道上發(fā)出的第一條消息就是genericIndication指示消息，包含callIdentifier和answerCall標(biāo)識(shí)；
3) TS收到genericIndication指示消息，注意不能轉(zhuǎn)發(fā)此消息，TS根據(jù)callIdentifier和answerCall標(biāo)識(shí)，唯一確定這個(gè)TCP連接與哪個(gè)呼叫關(guān)聯(lián)。
keep-alive機(jī)制
????? 為了維持NAT上打的"孔", 需要在各個(gè)通道上實(shí)現(xiàn)一個(gè)keep-alive機(jī)制。對(duì)于RAS通道，keep-alive實(shí)現(xiàn)就是靠輕量級(jí)的RRQ RAS消息和對(duì)應(yīng)的RCF響應(yīng)。對(duì)于H.225.0和H.245通道，keep-alive實(shí)現(xiàn)是靠發(fā)送空的TPKT包。?
FAQ(from TANDBERG)
What's the problem with getting H.323 through a firewall?
Firewalls typically block inbound connections. They can be configured to allow connections on a predetermined port to a given IP address. Unfortunately H.323 uses dynamically chosen ports for its call control and media. Some devices will chose these dynamic ports from a limited range, but this varies between manufacturers. This makes it difficult to statically configure firewall rules to allow inbound connections.
The typical symptoms of this problem are one way audio and video.
What's the problem with getting H.323 through a NAT?
A NAT device (Network Address Translation) hides the private IP addresses behind it, replacing them with a public IP address. Packets arriving at the NAT device are directed to the appropriate private IP address. H.323 messages often contain address information buried within them. A NAT device which does not understand H.323 will forward the message body on unaltered, passing unusable address information to the receiving endpoint.
Does H.460.18/19 tunnel through the firewall?
No. Tunneling involves packaging one protocol up within another to hide it - for example passing H.323 off as HTTP. H.460.18/19 is an extension to the H.323 standard that adds additional information to the existing H.323 messages.
參考：
ITU-T Recommendation H.460.18 (2005), Traversal of H.323 signalling across network
address translators and firewalls.
————————————————
版權(quán)聲明：本文為CSDN博主「移動(dòng)與射擊」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/vincent1941/article/details/2119996
