第1章.文檔說明

H.323是ITU-T提出的一個建議書。它是一個協議族，用來在IP分組交換網上實現語音通信、視頻通信和數據會議。H.323當前已發展到了第6個版本。

H.323第6版本的建議書長達300多頁，限於篇幅，不可能一一敘述。爲了對H.323有個直觀的瞭解，本文首先介紹H.323協議族的組成，這個部分主要介紹協議族中相關協議的功能；然後介紹H.323的各個組件，這個部分主要介紹各個組件的功能；在瞭解了協議和功能組件的基礎上，再重點講述H..323的通信過程，這個部分主要介紹呼叫信令控制和多媒體控制信令等的建立和釋放，以及多媒體信息的傳輸。

圖1 H.323協議棧

第2章.H.323的相關知識

2.1.H.323協議棧

H.323協議族是建立在運輸層之上的體系結構。正因爲建立在傳輸層之上，所以它屏蔽了底層網絡的差異，而使其與其他網絡的VOIP協議交互起來比較容易。圖1是H.323的協議棧。

從圖中可以看出，H.323有三個功能模塊：信令控制模塊、媒體傳輸模塊和數據會議（Data Conference）模塊。信令控制模塊又由H.225.0 認證/接受/狀態RAS（Registration/Admission/Status）信令、H.245媒體控制信令和H.225.0呼叫信令組成。媒體傳輸模塊由音頻傳輸和視頻傳輸兩部分組成，這兩部分各自又包括編碼標準、RTP實時傳輸和RTCP實時傳輸控制。數據會議模塊則主要由建立在TCP上的T.120協議族來負責。

這裏需要注意的是H.323只是H.32X多媒體通信標準系列中的一個。H.32X系列標準各自針對一種特定網絡上的多媒體通信。它們公用了很多協議，例如H.245就是大多數H.32X協議族系列的一個公共的協議。H.32X協議族包括：H.320是在N-ISDN上進行多媒體通信的標準，H.321是在B-ISDN上進行多媒體通信的標準，H.322是在有服務質量保證的LAN上進行多媒體通信的標準，H.324是在GSTN和無線網絡上進行多媒體通信的標準，而H.323爲現有的分組網絡PBN（如IP網絡）提供多媒體通信標準。

圖1所示的協議棧中的各個協議都比較複雜，我們將在單獨的部分中介紹它們。圖1中所示的協議棧是在什麼上面實現的？當然是在H.323的功能組成部分——組件上了，因此，下面介紹H.323的組件。

2.2.H.323的組件

2.2.1.H.323拓撲圖

圖2一個簡單的H.323拓撲圖

圖2給出了一個簡單的H.323系統的拓撲圖。可以看出，H.323一般有四個組件：Terminal（終端）、Gateway（網關）、MCU（Mutipoint Control Units多點控制單元）和Gatekeeper（關守）。Terminal、Gateway和MCU都可稱爲endpoint（端點）。

2.2.2.Terminal

Terminal是一個產生和終止H.323數據流／信令的endpoint。它是一個帶有H.323協議棧的器件，例如PC、嵌入式IP電話機和IP電話軟件Net2Phone等。

根據H.323的規定，Terminal必須支持音頻通信，而視頻通信和數據會議則是可選的。

2.2.3.Gateway

Gateway是H.323網絡中一個可選組件。Gateway最重要的作用就是協議轉換。通過Gateway，兩個不同協議體系結構的網絡得以通信。例如，有了Gateway，一個H.323終端能夠與PSTN終端語音通信。可以看出，當我們的通信要經過不同協議體系結構的網絡時，Gateway是必須的。

2.2.4.MCU

MCU主要負責多方會話。MCU由一個必須的MC（Multipoint Controller）和可選的多個MP（Multipoint Processor）組成。MC負責信令控制，MP負責混音、Transcode等媒體處理。

2.2.5.Gatekeeper

Gatekeeper也是H.323網絡的一個可選組件。Gatekeeper主要負責認證控制、地址解析、帶寬管理和路由控制等。

當H.323網絡中不存在Gatekeeper時，兩個endpoint是不需要經過認證就能直接通信。這不便於運營商開展計費服務，而且兩個endpoint的地址解析被分散到Gateway中，這無疑會加大Gateway的複雜度。另外，如果沒有Gatekeeper，擴充新功能（如添加帶寬管理和路由控制）是比較困難的。

Gatekeeper則恰好彌補了上述缺陷，當然也帶來了成本的提高。Gatekeeper本質上是將認證控制、地址解析、帶寬管理和路由控制等功能集成到一個器件中。這樣，當H.323網絡中存在Gatekeeper時，兩個endpoint要通信，必須先經過Gatekeeper的認證。然後Gatekeeper從endpoint提交的認證信息（如Net2Phone提供的號碼序列）中，獲取到兩個endpoint間的路由，從而讓兩個endpoint實現通信。當然，爲加強整個網絡的管理，我們可以方便地將帶寬管理和路由控制等功能方便地添加到Gatekeeper中。

2.2.6.小結

上面提到的組件只是邏輯上的功能組件，在具體的物理實現中，它們中的幾個有可能被集成到一個器件上。例如，Gateway、Gatekeeper和MCU有可能集成到一個器件上，就像鏈路層交換和網絡層路由往往能被集成到一個路由器上一樣。

2.3.信令控制協議

2.3.1.H.225.0 RAS信令

2.3.1.1.RAS是什麼

H.225.0 RAS認證/接受/狀態（Registration/Admission/Status）用來實現endpoint和Gatekeeper間的認證。RAS信令提供如下功能。

1)允許Gatekeeper管理endpoint。

2)允許endpoint向Gatekeeper提出各種請求，如認證請求、接受請求和帶寬調整等請求。

3)允許Gatekeeper響應endpoint的請求，接受或拒絕提供某項服務，如認證許可、帶寬調整和地址解析等。

2.3.1.2.RAS消息的格式

同其它信令一樣，H.225.0 RAS信令也是通過RAS消息來交互的。RAS消息的常用格式如下所示。

1)xRQ /*請求（一般情況下是，由endpoint發送至Gatekeeper），x隨具體請求的不同而不同*/

2)xRJ /* Gatekeeper發回的拒絕響應，x隨拒絕的內容的不同而不同 */

3)xCF /* Gatekeeper發回的確認響應，x隨確認的內容的不同而不同 */

當然，RAS消息對一些特殊情況有特殊的格式，此處不再累述。

2.3.1.3.RAS交互的一般過程

如圖1所示，RAS是建立在UDP上。RAS單播通信（如IP電話）一般使用UDP端口1719，RAS多播通信（如視頻會議）則一般使用UDP端口1718。

圖3 RAS交互過程

我們以RAS認證過程爲例來講述RAS的交互過程。圖3示意性地給出了RAS的認證過程。

可以看出，RAS的認證過程如下（其它交互過程是類似的）。

1)Gateway向Gatekeeper發送RRQ認證請求消息。RRQ認證請求給出了必要的認證信息。

2)Gatekeeper處理Gateway傳來的認證信息，並向Gateway回送相應的響應。如果認證成功，則回送RCF認證確認消息；如果認證失敗，則回送RRJ認證拒絕消息。

更完整的通信過程可參考第3章的內容。

2.3.2.H.245媒體控制信令

2.3.2.1.H.245媒體控制信令是什麼

媒體傳輸時，有很多配置需要調整：需要協商發送方的發送特性和接收方的接收特性，需要打開或關閉某邏輯傳輸信道，需要實時控制媒體流。H.245媒體控制信令就是用來實現上述媒體控制功能的。它的功能如下。

1)能力協商。H.323允許各endpoint具有不同的發送和接收能力。因此，兩個endpoint要通信，必須先通過H.245消息來協調各自的能力。

2)打開或關閉邏輯信道。H.323中，音頻通信、視頻通信和數據會議通信的信道是獨立的，H.245被用來管理這些信道。H.245本身使用邏輯信道0。

3)媒體流或數據流控制。H.245的反饋信息可用來調節endpoint的各項操作。

4)其它管理功能。主要還是用來協調endpoint間的行爲。例如，當發送endpoint的傳輸編碼改變時，接收endpoint也需做相應的改變，這是由H.245負責的。

2.3.2.2.H.245消息的封裝

圖4 H.245的封裝

圖4給出了H.245消息的封裝，這裏做幾點補充說明。

1)H.245信息是經H.245控制信道傳輸的，這個信道是可選的，例如在快速連接（Fast Connect）中，就沒有這個信道。關於快速連接請參考2.3.3的相關內容。

2)H.245邏輯信道通常是一個單獨的TCP連接，但是在快速連接等情況下，它是通過H.225.0呼叫信令隧道（Tunnel）實現的。這種情況其實是1)中所述情況中的一種。關於Tunnel，請參看第5章中的相關內容。

關於TPKT、ASN1等請參看相應的資料，此處不再累述。

2.3.2.3.H.245消息的類型和H.245的交互過程

H.245消息有如下四種常用的類型。

1)請求（Request）。例如，主從確定請求masterSlaveDetermination和終端能力配置請求terminalCapabilitySet。

2)響應（Response）。例如主從確定響應masterSlaveDeterminationAck和終端能力配置響應terminalCapabilitySetAck。

3)命令（Command）。例如發送終端能力配置命令sendTerminalCapabilitySet。

4)指示（Indication）。例如用戶輸入指示userInput。

H.245的交互過程與RAS的交互過程類似，可參考2.3.1.3和第3章的相應內容。

2.3.3.H.225.0呼叫信令

2.3.3.1.H.225.0呼叫信令是什麼

圖5 H.225.0呼叫信令的封裝

H.225.0呼叫信令，顧名思義是用來在兩個endpoint間建立或釋放一個呼叫信令連接。它部分地採用了Q.931（ISDN呼叫信令），並加上了一些適合分組交換網的特定內容；H.225.0呼叫消息也部分地採用了Q.932。

2.3.3.2.H.225.0呼叫信令的封裝

圖5給出了H.225.0呼叫信令的封裝，這裏做幾點補充說明。

1)H.225.0呼叫信令信道在TCP或UDP都可建立。

2)圖 5中所示的IE（Information Element）隨所帶信息的不同而不同。例如，SETUP有“Calling Party Number”、“Called Party Number”和“Display”等IE。

同樣地，TPKT，Q.931和ASN.1請參考相關資料。

2.3.3.3.H.225.0消息的類型和H.225.0交互過程

H.225.0呼叫信令的交互也是通過呼叫信令消息實現的。呼叫信令消息的常見類型是：Setup，Call Proceeding，Alerting，Information，Release Complet，Facility，Progress，Status，Status Inquiry，Setup Ackowledge，Notify，Connect。

呼叫信令的交互過程就是兩endpoint間交流呼叫信令消息的過程。圖6給出了一個基本的呼叫信令的交互過程。

圖6 RAS和H.225.0呼叫信令的建立過程

對圖6做些說明。

1)圖中給出的一個是最簡單呼叫信令交互過程。Gateway之間是直接交互的，而沒有通過Gatekeeper的中轉。

2)整個呼叫信令的建立過程能夠最簡化成兩步，即“Setup”和“Connect”。當然呼叫信令的釋放直接用“Release Complete”即可。

3)圖中給出的交互過程還有可選的步驟，如“Call Proceeding”、“Progress”和“Alerting”。這些步驟主要是用來避免超時錯誤和提供帶內（in-band）廣播等服務。

2.3.3.4.小結

前面我們已講述了3個媒體控制協議。這三個協議的執行順序是怎樣的？它們之間的關係又是怎樣的呢？

三個協議的執行順序是這樣的：H.255.0 RAS協議最先進行，然後H.225.0呼叫信令控制協議和H.245媒體控制協議同時進行。具體的過程可參考第3章的相關內容。

三個協議的關係：三個協議按照時間順序執行，各司其職，爲H.323體系提供好的媒體控制功能。

2.4.媒體傳輸相關協議

音頻、視頻等信息要傳輸，首先要編碼，這需要編碼協議。爲保證它們的傳輸質量（實時性等），我們用UDP來傳輸它們，但UDP的可靠性不好，所以我們需在UDP之上加上自己的檢錯、糾錯機制，這就是說我們要在UDP上加上另外的傳輸協議。

H.323協議體系中，從上到下與媒體傳輸相關的協議有：音頻編碼協議G.711和G.723.1等，視頻編碼協議H.261和H.263等，實時運輸協議RTP以及與其配套的實時運輸控制協議RTCP。

音頻編碼協議和視頻編碼協議請參看相應的標準。

RTP協議是用來提供端到端的實時運輸功能，但並不保證服務質量；而配套的RTCP協議是用來保證服務質量的。這兩個協議的詳細情況請參看RFC3550（RFC1889是過期標準）和另一篇文章《RTP協議分析》。

2.5.數據會議相關協議

這裏主要講建立在TCP上的T.120協議。

2.5.1.T.120是什麼

T.120是一個TCP之上的協議族，使用熟知端口1503。它用來提供如下的功能。

1)數據會議

2)白板、共享圖片。

3)文件傳輸。

4)即時文本聊天。

5)共享應用（Application sharing），這個尚未標準化。

2.5.2.T.120協議棧

圖7 T.120協議棧

圖7虛線框內所示的即是T.120的協議棧，各協議的功能請參考圖中的文字說明。如想深入瞭解整個協議棧，請參看相關H.323等相關文檔。

第3章.H.323的通信過程

3.1.總覽

圖8一個典型的H.323的通信過程

圖8給出了一個典型的H.323通信過程。可以看出這個通信過程分爲4步。

1)建立RAS信令。這主要完成認證、地址解析等功能。

2)建立呼叫信令。這主要是通過Setup，Alerting，Connect等步驟來完成。

3)建立呼叫控制（即媒體控制）。這主要完成協商endpoint的能力，打開或關閉媒體邏輯信道等。

4)傳輸音頻或視頻等信息。

需要注意的是在快速連接（Fast Connect）模式下，並沒建立單獨的呼叫控制信道，所有的呼叫控制信息以“隧道”的方式在呼叫信令信道中傳輸。

下面分步驟地來講解一個完整的通信過程。所給的例子中，左邊的終端T1向右邊的終端T2發起媒體通信。當然，T1和T2所在的網絡中是有Gatekeeper的，然而我們假定T1與T2是直接路由的。

3.2.建立呼叫

圖9給出了呼叫建立的過程。圖中的綠實線表示RAS信息，而黑虛線表示H.225呼叫信令信息。圖中的呼叫建立過程敘述如下。

1)T1向Gatekeeper發送認可請求ARQ（Admission Request）。

2)Gatekeeper確認T1的ARQ，向T1回送ACF。

3)T1發送“Setup”信息給T2。

4)T2向T1回送一個“Call Proceeding”響應，表明呼叫正在建立中。這個時候，如果T2已經向GateKeeper註冊，則轉6)。

5)T2到Gatekeeper處註冊。

6)T2向T1發送“Alerting”信息，表明T2正在建立呼叫。

7)T2向T1發送“Connect”信息，表明已經成功地在T1和T2間建立了呼叫連接。

圖9建立呼叫的過程

圖10建立呼叫控制的過程

3.3.建立呼叫控制

圖10給出了呼叫控制的建立過程。整個建立過程比較簡單，就是T1（T2）向T2（T1）發送某個請求，然後T2（T1）向T1（T2）確認相應的請求。

3.4.傳輸媒體信息

圖11媒體傳輸示意圖

圖12釋放呼叫連接的過程

圖11給出了媒體信息傳輸的示意圖。RTP用來提供端到端的實時運輸功能，但並不保證服務質量，而配套的RTCP用來保證服務質量。

3.5.釋放呼叫連接

圖12給出了釋放呼叫的示意圖。整個流程大致如下。

1)T1和T2向對方發送H.245消息“End Session Command”來建議釋放呼叫連接。

2)T2向T1發送H.225信令消息“Release Complete”來釋放呼叫連接。

3)T1和T2各自從Gatekeeper上登出。

第4章.H.323 VS SIP

H.323 是ITU-T提出的建議標準。它是基於電信網信令和協議制定的IP多媒體標準，而不是爲IP電話專門提出的。因此以H.323爲標準構建的多媒體通信網很容易與傳統PSTN 電話網兼容，從這點上看， H.323 更適合於構建電信級大網。國際上幾乎所有的商業性 IP 電話網或視頻會議網都是以 H.323 爲基礎的。

SIP是IETF提出的標準，對應的RFC文檔爲RFC3261。它利用已有的IP 網絡協議提供多媒體業務，協議簡單但功能也比較簡單。它的設計思想是，將網絡設備的複雜性推向網絡邊緣，是一個分散式協議。SIP適合用來構建家庭網絡和小商業網絡。

總體來說，H.323適合集中管理，適合用來構建電信級大網，因而在企業級應用上佔有了大部分市場。而SIP實現簡單，但功能也相對簡單，適合用來構建小型網絡，因而在家庭應用等應用上佔有了很大的市場。

第5章.常見的疑問

5.1.爲什麼看不到單獨的H.245包

用Wireshark（Ethereal）對Net2Phone的VOIP通信抓包，爲什麼看不到單獨的H.245包？

默認情況下，VOIP呼叫採用的是快速連接（Fast Connect）。在快速連接下，並不建立單獨的H.245控制信道，所有的H.245包都以“隧道”的方式在H.225.0的呼叫信令信道中傳輸。事實上，在其它很多情況下，H.245包也是以“隧道”的方式在H.225.0的呼叫信令信道中傳輸。

因此，逐層展開抓到的H.225.0包，會發現其中有些包的“h245Tunneling”標誌被置爲“True”，這表明這些H.225.0包裏傳輸了H.245信息。事實上，可以在這些包裏找到“parallelH245control”域，這些域的內容就是H.245信息。

第6章.參考資料

[1]http://www.itu.int/，ITU的主頁，上面有H.32x系列標準。

[2]http://www.packetizer.com/iptel/h323/，上面有很多優秀的H.323參考文檔，並且這些文檔都是免費的。

[3]http://www.iec.org/online/tutorials/h323/index.htm，這裏有來自Intel的H.323指南。

[4]http://www.openh323.org/，這裏有開源的H.323實現工程。

[5](An H.323 open source implementation project)

有關視頻會議系統用到的相關協議