【正文】 擇，依據(jù)被叫號碼信息選擇對端GW，并將對端GW呼叫信令地址返回給發(fā)端GW。（可以通過GK也可以不通過GK），若呼叫成功。在通話中，系統(tǒng)執(zhí)行計費、管理等功能。通話結束，拆除呼叫連接并終止計費。 上圖主要示意了記賬卡用戶的通信過程，主叫號碼用戶及PC用戶涉及的過程與之基本一致。 在通信過程中，網關分別完成電話網側的傳輸（如 ）和IP電話網側的傳輸（TCP/UDP/IP）；執(zhí)行兩側不同的話音編碼方法；對來自電話網側的信令和來自IP電話網側的信令進行必要的翻譯，當兩端有網關不處理的補充業(yè)務時，相應的電話網信令由網關透明傳送至對端。在通信過程中，主要可分為三個部分：（1） RAS通信，主要涉及的報文有ARQ/ACF/ARJ/LRQ/LCF/LRJ等。（2） ，主要涉及的報文有Setup、Call Proceeding、Alerting、Connect、Release Complete等；（3） ，建立邏輯通道，包括控制通道和一般通道。網關應支持的主要過程有確定主從過程、能力交換過程、邏輯通道建立和關閉信令過程、模式請求過程、往返時延確定過程、維護環(huán)回信令過程等。 上述各過程涉及到的協(xié)議及協(xié)議中的報文、。對于實時傳真業(yè)務，然后主叫端網關對被叫端網關進行尋址，被叫網關再去建立與被叫的連接；；至此通過IP網絡的“虛擬”，兩端傳真機實現(xiàn)實時通信。（1） IP電話業(yè)務的撥號程序 IP電話業(yè)務的撥號程序分為記賬卡IP用戶的撥號程序和主叫IP用戶的撥號程序兩種情況。a. 記賬卡IP用戶的撥號程序 對于記賬卡IP用戶，持卡用戶可在江西省IP電話網范圍內所有城市中的任一部話機（PSTN話機或數(shù)字移動話機）或PC機上撥打記賬卡IP用戶的IP電話業(yè)務接入碼17900，當PSTN、數(shù)字移動通信網或IP網接收到17900接入碼后，他們均將此次呼叫轉接至當?shù)氐腎P電話網關，隨后由IP網關發(fā)出錄音通知提示持卡用戶按序輸入記賬卡號和密碼。在持卡用戶的記賬卡號和密碼得到確認后，IP網關提示持卡用戶撥入被叫電話號碼。b. 主叫IP用戶的撥號程序 IP電話網中的主叫IP用戶包括PSTN的IP主叫用戶和數(shù)字移動網和IP主叫用戶。IP主叫用戶所使用的話機相對IP網來講是固定不變的。對于PSTN的IP主叫用戶，其不具備漫游功能，IP主叫用戶撥打PSTN主叫IP用戶的IP電話業(yè)務接入碼17901后，PSTN將此次呼叫轉接至當?shù)氐腎P電話網關，IP網關接收主叫用戶電話號碼，并在主叫用戶電話號碼前加發(fā)本地的長途區(qū)號，到用戶認證中心進行用戶身份認證，得到確認后由IP網關提示主叫用戶撥入被叫電話號碼。對于數(shù)字移動通信網中的IP主叫用戶，其可使用同一部移動話機在江西省IP電話網范圍內的所有城市進行IP電話呼叫，移動網中的IP主叫用戶撥打移動主叫IP用戶的IP電話業(yè)務接入碼17901后，移動網將此次呼叫轉接至當?shù)氐腎P電話網關，IP網關接收主叫用戶電話號碼，直接到用戶認證中心進行用戶身份認證，得到確認后由IP網關提示主叫用戶撥入被叫電話號碼。（2） IP傳真業(yè)務的撥號程序 IP傳真業(yè)務的撥號程序只有一種，即主叫IP用戶的撥號程序，IP傳真業(yè)務中的主叫IP用戶只包括PSTN的IP主叫用戶。 傳真用戶撥打IP傳真業(yè)務接入碼17902后，PSTN將此次呼叫轉接至當?shù)氐腎P電話網關，IP網關接收主叫用戶電話號碼，并在主叫用戶電話號碼前加發(fā)本地的長途區(qū)號，到用戶認證中心進行用戶身份認證，得到確認后由IP網關提示主叫用戶撥入被叫傳真電話號碼。 用戶使用IP電話業(yè)務時需進行身份認證，通過認證的用戶經授權使用其業(yè)務，用戶身份認證的關鍵技術問題涉及到認證方式、認證協(xié)議、用戶數(shù)據(jù)庫。 與業(yè)務類型相適應，認證方式亦分成兩種形式： －記賬卡認證方式 －主叫號碼認證方式 記賬卡方式以卡號及密碼表征用戶的身份信息，用戶在使用時應按錄音提示撥入卡號及密碼，由網關通過認證中心進行認證。 主叫號碼方式以主叫用戶號碼作為用戶的身份信息，當用戶撥打IP電話時由電話網將主叫用戶號碼送至IP電話網，然后據(jù)之通過認證中心進行認證。 用戶數(shù)據(jù)庫的位置決定了認證過程和可能采用的認證協(xié)議。相對于電話－電話呼叫而言，用戶數(shù)據(jù)庫的位置可以在電話網側，亦可在IP網側。 由于目前智能網的業(yè)務和功能越來越完善，若將用戶數(shù)據(jù)庫設在電話網側則可借用智能網的功能，通過SCP/SSP與IP電話網中相應信令點的互操作完成對用戶的身份認證。這種方案的優(yōu)點是可以利用智能網的現(xiàn)有資源，但缺點亦較多：一是需要修改目前“300”業(yè)務的業(yè)務流程以及智能網相關的數(shù)據(jù)，使實驗網對目前智能網業(yè)務影響較大同時影響實驗網本身的建設及發(fā)展速度；二是雖然IP和智能網的結合也是目前的一種發(fā)展方向，但技術復雜、標準化程度很低；三是這種方式會影響PC電話業(yè)務的開展。因此，建議IP電話網采用將用戶數(shù)據(jù)庫設在IP網絡側的方案。 用戶數(shù)據(jù)庫設在IP網絡側需要建設認證中心和用戶數(shù)據(jù)庫。 與IP電話網的域的組成相對應，建議IP電話網在全網集中設立用戶數(shù)據(jù)庫及認證中心，以方便業(yè)務開展和管理，而且容易實施記賬卡IP電話異地漫游功能。在IP電話網的遠期方案中或者用戶數(shù)量發(fā)展迅速時，為減輕集中式用戶數(shù)據(jù)庫的壓力，對于主叫IP電話可采用獨立的分散式管理，對于記賬卡IP電話可考慮分布式管理，此時亦可與全網域的劃分配合考慮。 根據(jù)在認證過程中對RAS的采用與否，認證協(xié)議的方案可分為： 方案一：：由GW收集用戶信息后使用RAS通過GK到認證中心進行身份認證。GK與用戶數(shù)據(jù)庫間的認證協(xié)議可以在數(shù)據(jù)庫接口、LDAP等方案中進行選擇。這種方案需要對RAS的消息內容進行一些擴充，特別是在認證授權和認證拒絕等方面。 方案二：采用RADIUS協(xié)議：由GW收集用戶信息后，GW作為RADIUS Client與認證中心設置的RADIUS Server進行交互完成身份認證。 具體的方案選擇應考慮到工程和設備廠商的實際情況后確定，同時應仔細考慮實驗網遠期實施時可能的分布式設立用戶數(shù)據(jù)庫和分布式用戶認證需求，在分布式用戶認證導致的漫游問題以及實驗網和其它網絡的互通要求等方面預先作出規(guī)劃。 用戶認證過程如圖4－15和圖4－16示意：（1） 電話用戶 對應認證協(xié)議方案一：a：用戶輸入賬號和密碼；b：GW將用戶數(shù)據(jù)傳給GKc：GK向用戶數(shù)據(jù)庫發(fā)出認證查詢請求；d，e：數(shù)據(jù)庫完成查詢，反饋查詢結果。 對應認證協(xié)議方案二：a：用戶輸入賬號和密碼；b,c：GW使用RADIUS協(xié)議向認證中心（RADIUS Server、用戶數(shù)據(jù)庫）查詢并反饋結果。（2） PC用戶a：PC將用戶數(shù)據(jù)傳送給GK；b：GK向數(shù)據(jù)庫發(fā)出認證查詢請求；c，d：數(shù)據(jù)庫完成查詢，反饋查詢結果。 用戶數(shù)據(jù)庫存放用戶信息及其帳戶信息，是全網的業(yè)務核心之一。數(shù)據(jù)庫的結構應進行良好的設計以滿足業(yè)務需求和性能要求。本可研建議對于記賬卡用戶在庫內的信息記錄包含如下內容： 卡號－密碼－類型－節(jié)余金額－卡狀態(tài)－啟用日期－失效日期－使用標志 數(shù)據(jù)庫的容量應根據(jù)全網用戶容量進行規(guī)劃。 IP電話網的計費系統(tǒng)由計費信息采集點和計費中心組成。計費信息采集點負責計費信息的采集和上傳，計費中心負責計費信息的處理。 當不具備統(tǒng)一的各專業(yè)計費中心條件時，IP電話網單獨設置自身的計費中心。對應于IP電話網初期的集中式管理結構，初期的計費系統(tǒng)也為集中式，全網設置計費中心。對于IP電話網遠期可能的分布式結構，可以建立全省和地市兩級計費中心，全省中心主要負責計費結算問題。 根據(jù)IP電話呼叫流程所涉及的環(huán)節(jié)，計費信息采集點可設在GW或GK。計費信息采集點的具體設置需要呼叫控制流程的配合。 目前對于Call Detail Record 的具體內容尚無標準。本可研建議IP電話業(yè)務的CDR至少應包括如下內容：－Start Time－Stop Time－Caller ID－Caller Number－Origination GW IP Address－Destination GW IP Address－Origination GK IP Address－Destination GK IP Address－service class 為適應業(yè)務的不同特點，可選的計費信息可選擇：－Qos relative to what was purchased－Codec Selected－Network Metric（Number of hops）－Round Trip Delay－Reason the Call was Dropped－Packet Loss 計費信息采集點采集CDR，然后將之送至計費中心進行計費處理，對于不同的用戶類型，計費過程亦不同。（1） 主叫號碼用戶計費過程 對于主叫號碼用戶，計費中心根據(jù)CDR按計費周期進行處理，生成清單下發(fā)。（2） 記賬卡用戶計費過程 對于記賬卡用戶，要求實時計費，并能實時斷線。 對于有余額限制的情況時，計費系統(tǒng)應具備計費監(jiān)視功能。計費中心可以從用戶數(shù)據(jù)庫提取余額給計費信息采集點或折算成最大可能話時間傳給計費點，計費點啟動相應的定時器以免用戶透資。 IP電話業(yè)務采用單向計費，對于到達設有IP網關的城市，IP電話業(yè)務的話費為：IP使用費時長；對于到達未設IP網關的城市，IP電話業(yè)務的話費為（IP使用費＋PSTN使用費）時長。 IP實時傳真業(yè)務可采用按頁計費或按時長計費的方式。 全網計費中心負責全網計費，計費統(tǒng)計，計費查詢等。 對于電話用戶，計費查詢通過各節(jié)點網關設備的IVR與計費中心交互；對于PC用戶，建議計費查詢以WWW方式進行。 對于記賬卡用戶的金額信息，建議與用戶數(shù)據(jù)庫合設。 對于CDR，建議建設CDR數(shù)據(jù)庫和脫機存儲設備進行在線和脫機存儲。 根據(jù)IP電話網的初期集中式結構，網絡管理亦相應采取集中管理方式，設置全網網管中心，負責完成各項管理功能。 網管中心著重進行設備管理，其管理對象為實驗網各節(jié)點設備。 網管中心和其被管設備之間建議采用CMIP協(xié)議的Q3接口。由于目前大部分與IP有關的設備只支持SNMP協(xié)議，網管接口目前亦可選擇SNMP協(xié)議。 。一般地，網管中心和被管設備之間的網管信息模型應采用一致的MIB庫，其內容至少包括系統(tǒng)信息、配置信息、告警信息、性能統(tǒng)計信息等。 網管中心應實現(xiàn)的管理功能為故障管理、配置管理、性能管理和安全管理等。 業(yè)務管理是IP電話網的重要方面。針對IP電話業(yè)務，IP電話網可以建立起用戶管理系統(tǒng)、網關管理系統(tǒng)、業(yè)務統(tǒng)計系統(tǒng)等。（1） 用戶管理系統(tǒng)負責主叫號碼用戶和記賬卡用戶的管理，其功能可有：－用戶管理功能，即用戶的開戶、銷戶，記賬卡的卡號生成、發(fā)卡、銷卡，以及用戶權限管理等；－用戶信息管理，即用戶信息查詢、統(tǒng)計等；－用戶密碼管理，記賬卡用戶的密碼生成、密碼修改等；－數(shù)據(jù)備份功能。 IP電話網對用戶的管理在初期可采用分散受理集中管理的方式，在遠期可采用集中和分散相結合的方式。 用戶管理系統(tǒng)應包括業(yè)務受理點和用戶管理中心系統(tǒng)。 業(yè)務受理系統(tǒng)應包括業(yè)務受理點和用戶管理中心系統(tǒng)。 業(yè)務受理點設置在各節(jié)點，作為用戶管理系統(tǒng)的前臺，接受業(yè)務申請，如主叫用戶的開戶申請、記賬卡的啟用、修改密碼等。業(yè)務受理點由各節(jié)點運營部門建設。（2） 網關管理系統(tǒng)負責網關信息的收集維護，網關與其所轄電話號碼的匹配配置，GW路由策略的配置等。（3） 業(yè)務統(tǒng)計系統(tǒng)根據(jù)自身收集來的數(shù)據(jù)以及網管中性能管理所收集的數(shù)據(jù)進行全網業(yè)務的分析與統(tǒng)計。 對IP電話的特性分析可知，影響IP電話質量的因素有： －編解碼方法 －時延 －時延抖動 －丟包 －比特差錯 在上述因素中，時延和時延抖動影響著聽覺感覺，而丟包和比特差錯影響著對話音包的解碼。（1） 全程時延指標 根據(jù)ITU－T ，語音通信的單向門限為400ms。根據(jù)電話網的經驗，在400ms時延時，即使沒有回波，人們對通話的感覺也不好。本可研建議全程往返時延不大于450ms。（2） 時延指標的分配建議 涉及時延產生的因素有網絡時延、buffer排隊時延、編碼及打包時延、處理時延等。編碼及打包時延由語音編碼方法及打包方法確定，對于G。，此項時延不應超過40ms。處理時延因設備而異。排隊是為了降低時延抖動的影響，其時延與buffer大小。網絡時延主要由網絡節(jié)點設備時延和中繼傳輸時延組成。由于Internet業(yè)務特性變化雜亂，網絡時延變化較大?？紤]到CHINANET網絡的能力和設備能力，本可研建議對國內全程時延指標分配如下 圖4－17示意： ，而RTP采用UDP作為網絡層承載協(xié)議，因此話音分組的傳送是不可靠的。當網絡擁塞、傳輸損傷、超過生存期時，丟包就可能會發(fā)生。典型語音編碼允許的丟包和比特差錯率為3％。 IP網絡對時延的影響 在IP電話的全程時延中，IP網絡的時延占了很大的比重。為了控制時延，建議CHINANET試驗為IP電話網提供QoS。根據(jù)CHINANET網絡的狀況，可提供QoS的途徑有：設置IP優(yōu)先級，啟用網絡節(jié)點設備的隊列管理及RED/WRED，進行RTP頭壓縮等。，所以亦可以局部試驗RSVP協(xié)議。另外，密切注意涉及網關設備的路由不對稱性，通過路由協(xié)議調整配置，盡量保證往返路由的對稱性。 RTCP可以用來對IP電話系統(tǒng)的性能進行大致的監(jiān)測。通過RTCP的收、發(fā)報文，系統(tǒng)可了解性能狀況。 從前面各項分析可知，應采取綜合的手段提高IP電話的服務質量。 為了使話音傳輸質量能達到用戶可以接受的程度，建議根據(jù)IP網絡帶寬建設及使用情況，按照網絡狀況管理呼叫，并限制業(yè)務規(guī)模。 IP電話網支持系統(tǒng)的性能也是提供業(yè)務服務質量保證的重要方面，例如呼叫建立時間（涉及網關處理能力指標、關守處理能力指標、身份認證的響應時間等）、計費準確性等，在工程實施中應提出明確要求。 對于IP實時傳真業(yè)務，應在兩端速率不匹配或網絡擁塞等情況下保證傳真質量，特別是。 IP電話網的安全問題可以從網絡安全和業(yè)務安全兩個方面考慮。 網絡安全：擬在網絡組織、網絡節(jié)點、網絡數(shù)據(jù)及設備配置方面考慮安全措施。例如實驗網節(jié)點連入IP網絡的路由穩(wěn)定性、節(jié)點設備的接入口令安全管理、支持中心的安全等。 業(yè)務安全：擬在用戶數(shù)據(jù)、業(yè)務流程和業(yè)務處理等方面考慮安全措施。例如用戶數(shù)據(jù)庫的安全、。建議IP電話網在支持中心采取設置防火墻等安全措施。對于用戶認證采取加密等技術。五、 實驗網容量、電路估算及能力要求 IP電話網是在現(xiàn)有電話網和現(xiàn)有IP網基礎上組建的一種新型電信業(yè)務網，由于IP電話網的網絡承載能力及最終的IP電話用戶數(shù)量與現(xiàn)有IP網的網絡承載能力是密切相關的，因此采用傳統(tǒng)的用戶預測方法顯然不符合IP電話業(yè)務實驗網的真實情況。為此在本可研中，對于IP電話網的承載容量及建設規(guī)模按如下方法考慮。 由于IP電話的網絡承載主體主要為現(xiàn)有的IP網絡，因此在IP電話網的容量測算時，應充分考慮實驗網容量對現(xiàn)有IP網絡的影響。 由于IP電話技術本身的獨特性，在IP電話網的容量測算時，也應考慮容量的大小對IP電話網業(yè)務質量的影響問題。 由于IP電話為新生事物，無歷史經驗和歷史數(shù)據(jù)可參考，所在IP電話網的容量測算工作若采用預測方法則較難進行。本可研擬從上述兩個影響問題出發(fā)，主要從目前IP網絡的承載能力角度去初步取定實驗網的用戶容量。上述兩個影響是相輔相成的?，F(xiàn)有IP網冗余承載能力決定了實驗網中的用戶容量，而IP電話的通話質量又主要取決于所用IP網絡的承載能力。待對IP電話網的業(yè)務積累了一定的數(shù)據(jù)以后，則可據(jù)之選用適當?shù)哪Ｐ腿ヮA測實驗網的用戶數(shù)量發(fā)展趨勢，并從IP電話網本身及IP網絡等各方面綜合考慮解決發(fā)展問題。 TCP/IP采用基于統(tǒng)計復用的通信方式，根據(jù)M/M/1排隊模型，網絡的通信量強度P應小于1，網絡才不致出現(xiàn)大量的丟包和大時延。因此，為保證IP電話的服務質量，由IP電話業(yè)務引起的IP網絡業(yè)務量增加應在IP網絡可接受的通信量強度范圍內。所以，應根據(jù)IP網絡的承載能力和網絡利用情況來決定它所能承載的IP電話業(yè)務量，否則不僅導致既有的IP業(yè)務擁塞，而且使得IP電話業(yè)務亦無法正常