導(dǎo)言：作為寫作愛好者，不可錯過為您精心挑選的10篇sip協(xié)議，它們將為您的寫作提供全新的視角，我們衷心期待您的閱讀，并希望這些內(nèi)容能為您提供靈感和參考。

篇1

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2016）25-0035-02

1 引言

第三代合作伙伴3GPP選擇sip協(xié)議作為第三代移動通信系統(tǒng)的IP多媒體子系統(tǒng)（IMS）心靈協(xié)議，是因其具有靈活、無縫和可擴展性，它將逐漸成為下一代網(wǎng)絡(luò)NGN中關(guān)鍵控制協(xié)議之一。它可以滿足多媒體通信與網(wǎng)絡(luò)電話的要求，所以很多的通訊公司均先后研發(fā)出了支持SIP的服務(wù)產(chǎn)品與終端產(chǎn)品。為充分適應(yīng)這些技術(shù)的發(fā)展，SIP協(xié)議需要進(jìn)行進(jìn)一步的完善與擴充，但是如果協(xié)議在設(shè)計環(huán)節(jié)出現(xiàn)任何問題都會給系統(tǒng)帶來難以預(yù)料的影響，所以為保證協(xié)議的穩(wěn)定性和安全性，應(yīng)在早期開發(fā)時盡可能挖掘其隱蔽的問題并找出解決方案。

目前研究SIP協(xié)議主要涉及以下幾方面：基于SIP的應(yīng)用于服務(wù)[3]；SIP測試工具和方法；其他協(xié)議與SIP協(xié)同工作。因時間著色Petri網(wǎng)TCPN[2]在描述帶有較復(fù)雜的交互動作和時間約束的系統(tǒng)過程中具有明顯的優(yōu)勢，故本文以TCPN為模型分析工具進(jìn)行SIP協(xié)議分層TCPN模型的構(gòu)造，并在不同狀態(tài)下實現(xiàn)分層建模。

2 SIP協(xié)議事務(wù)處理

SIP協(xié)議通過事務(wù)進(jìn)行會話控制，其主要事務(wù)有INVITE、non_INVITE事務(wù)。INVITE事務(wù)完成會話的創(chuàng)建，non_INVITE事務(wù)則完成會話的保持與關(guān)閉。SIP端系統(tǒng)（User Agent，UA）是連接服務(wù)器從而發(fā)送服務(wù)請求的一種應(yīng)用程序。因UA向服務(wù)器發(fā)送服務(wù)請求并接收來自服務(wù)器的響應(yīng)，故一個UA有UAS（用戶服務(wù)器）和UAC（用戶客戶端）兩部分，這兩部分就是SIP協(xié)議中的兩個最關(guān)鍵的參與者，UAC創(chuàng)建呼叫請求，UAS接受呼叫給出響應(yīng)。

在SIP的請求消息中，最常用的有INVITE、REGISTER、CANCEL和BYE。其響應(yīng)消息有1xx、2xx、3xx、4xx、5xx、6xx6種。SIP的呼叫方式有3種：從UAC到UAS的直接呼叫、從UAC發(fā)出的重定向呼叫、服務(wù)器發(fā)起呼叫。本文主要針對應(yīng)用最廣的直接呼叫進(jìn)行分層建模。

3 SIP協(xié)議TCPN分層建模

本文應(yīng)用CPN Tools[4]進(jìn)行INVITE事務(wù)的分層建模，并在不同的抽象層次上描述協(xié)議行為細(xì)化模型。這種方法在一個層次中描述協(xié)議細(xì)節(jié)，有利于優(yōu)化或局部完善協(xié)議模型，也能有效把握模型規(guī)模，便于確認(rèn)模型與分析協(xié)議性質(zhì)。

SIP協(xié)議的TCPN分層模型中的10個模型頁分別處于不同的層次，每頁所描述的是對應(yīng)抽象級別上的協(xié)議功能，低級別頁作為高級別頁的替代變遷子頁。各層次模型頁功能描述如下表1。各層內(nèi)部模塊細(xì)化是依據(jù)UAS與UAC在INVITE事務(wù)執(zhí)行過程中具備的不同狀態(tài)進(jìn)行的，因在terminated狀態(tài)下協(xié)議無行為，而僅表示終止事務(wù)，故沒有單獨描述此狀態(tài)。

3.1 總體流程建模

SIP協(xié)議分層TCPN模型的top page（頂級頁）如下圖1所示，它總體描述了協(xié)議運行的網(wǎng)絡(luò)拓?fù)洌渲惺褂昧?個替代變遷對NET、UAS和UAC在協(xié)議運行過程中的交互行為進(jìn)行描述。UAC通過NET向UAS發(fā)送REQUEST型數(shù)據(jù)，UAS將RESPONSES型數(shù)據(jù)通過NET回傳給UAC。

Client頁用以描述UAC的行為，下圖2所示為其頁模型。圖中的3個替代變遷對應(yīng)的子頁能夠更加細(xì)致地描述處于不同狀態(tài)的UAC端行為。庫所Scene用以描述UAC的行為，變遷TransErr可以模擬協(xié)議在不同條件下出現(xiàn)傳輸層錯誤時所采取的處理方式。

3.2 網(wǎng)絡(luò)層建模

下圖3所示為NET頁模型，描述的是由UAC到UAS的網(wǎng)絡(luò)傳輸建模。庫所Schannel_Em記錄的是有多少個消息被成功地傳送到了UAS端，其初值為0。庫所CollectorCTS用以收集不可靠鏈路丟失的消息。變遷RCTS與CTOS用以模擬不可靠鏈路。不可靠鏈路的具體建模方式如表2所示。

通過上述時間類型、弧表達(dá)式及防衛(wèi)表達(dá)式的應(yīng)用，可模擬存在重復(fù)數(shù)據(jù)包、延遲、丟包的不可靠鏈路。若對其某些參數(shù)做適當(dāng)?shù)男薷?，便可動態(tài)調(diào)整其鏈路的可靠性，以此來真實地模擬不可靠鏈路。

3.3 具體行為建模

本文表1中的Sproceeding、Ccalling、Cproceeding等底層模型頁描述UAS和UAC在不同狀態(tài)下處理事件的過程，也就是對協(xié)議的具體行為建模。下文以UAC端處于Ccalling狀態(tài)時的應(yīng)答消息處理行為為例，闡述具體行為的模型描述方式。

下圖4所示為UAC處于Ccalling狀態(tài)時處理INVITE消息的模型，即Ccalling頁模型。圖中CallTimer表示UAC處于超時狀態(tài)時消息的處理過程，CallResp表示UAC收到UAS應(yīng)答時對消息的處理過程。庫所TimerAorB用以控制A與B兩個定時器的觸發(fā)。融合庫所cloneCs用隊列存放UAC每次狀態(tài)的變化，其隊首為UAC的當(dāng)前狀態(tài)，Scenec記錄UAC的當(dāng)前狀態(tài)和導(dǎo)致UAC變?yōu)榇藸顟B(tài)的事件。Message存放初始條件下從SIP協(xié)議上層收到的INVITE請求。Channel_Em用以記錄當(dāng)前是否收到UAS的應(yīng)答，其初值為0。

當(dāng)收到UAS會送的響應(yīng)消息時，變遷CallResp被點火執(zhí)行，即運行其對應(yīng)的函數(shù)代碼。此函數(shù)代碼中sta與st均為SCENEC型變量，st是處理消息前UAC的狀態(tài)，sta為處理消息后UAC的狀態(tài)。Action部分調(diào)用函數(shù)call_resp（st，resp）完成UAC對不同類型響應(yīng)消息的處理，該函數(shù)代碼如下：

由上述代碼可知，處理類型為r2xx的應(yīng)答消息后UAC處于TERM狀態(tài)，處理類型為r3xx的應(yīng)答消息后處于COMP狀態(tài)，處理類型為r1xx的應(yīng)答消息后處于PROC狀態(tài)。

4 總結(jié)

本文給出了SIP協(xié)議處理INVITE事務(wù)的TCPN分層模型，對該協(xié)議總體流程、網(wǎng)絡(luò)層、UAS與UAC間的具體行為在不同模型層次上分別進(jìn)行建模。該層次模型規(guī)?？煽?、功能劃分直觀、數(shù)據(jù)結(jié)構(gòu)完備，為建模后期協(xié)議的驗證與改進(jìn)提供了較完善的模型基礎(chǔ)。

參考文獻(xiàn)：

[1] 姜秀玉，楊峰，崔再惠.SIP協(xié)議實現(xiàn)中消息解析的研究[J].計算機工程與設(shè)計，2010（7）.

篇2

【中圖分類號】TP3 11.1 【文獻(xiàn)標(biāo)識碼】A 【文章編號】1672-5158（2013）01―0085―02

1 引言

VOIP（基于網(wǎng)絡(luò)的語音傳送）是語音通信發(fā)展的趨勢。大多數(shù)電信廠商均認(rèn)為，雖然目前VOIP在語音通信流量中只占很少的比例，但隨著時間的推移和技術(shù)的發(fā)展，VOIP電話語音所占比例正快速增長。作為實現(xiàn)VOIP系統(tǒng)的軟交換協(xié)議，會話控制協(xié)議（SIP）和H.323、XMPP協(xié)議就是其中的三大主流技術(shù)，其中，SIP信令控制協(xié)議正越來越受到人們的關(guān)注。

2 SIP協(xié)議

SIP最早源于二十世紀(jì)九十年代中期哥倫比亞大學(xué)提出的研究成果，后經(jīng)IETF的一個標(biāo)準(zhǔn)化應(yīng)用控制（信令）協(xié)議。眾所周知，它可用來建立、修改以及終止多個參與者參加的多媒體會話進(jìn)程。參與會話的成員可以通過單播連網(wǎng)、組播方式或者兩者結(jié)合的形式進(jìn)行通信。并能動態(tài)調(diào)整和修改會話屬性（如會話帶寬要求、傳輸?shù)拿襟w類型、媒體編解碼格式等）。

SIP協(xié)議中有客戶機和服務(wù)器之分?？蛻魴C是向服務(wù)器發(fā)送sIP請求并能夠與服務(wù)器建立連接的終端應(yīng)用程序。用戶（User Agent）和（Proxy）中都包含客戶機的應(yīng)用。服務(wù)器是一個邏輯實體，它響應(yīng)客戶機發(fā)出的SIP請求，提供接收、拒絕和重定向等服務(wù)，并回送應(yīng)答的應(yīng)用程序，主要包括用戶服務(wù)器、服務(wù)器、重定向服務(wù)器、注冊服務(wù)器等四類服務(wù)器：

SIP協(xié)議最初規(guī)定了六種信令：REGISTER、INVITE、ACK、BYE、CANCEL、OPTIONS。其中REGISTER用于客戶端向注冊服務(wù)器等級和綁定用戶的位置等消息；INVITE和ACK用于創(chuàng)建會話呼叫，成功建立呼叫會話，或者用于改變已經(jīng)建立以后會話屬性；BYE用以終結(jié)和斷開已經(jīng)建立的會話；CANCEL用于終止已經(jīng)發(fā)起但還未完全建立會話的請求；OPTIONS用于查詢其它用戶和服務(wù)器能力。

SIP在設(shè)計上充分考慮了對其它協(xié)議的擴展適應(yīng)性。它支持許多種地址描述和尋址，包括用戶名@主機地址；被叫號碼@PSTN網(wǎng)關(guān)地址；Tel：010-5 9988888普通電話的描述等。這樣，SIP主叫按照被叫地址就可以識別出被叫在模擬電話網(wǎng)絡(luò)上的位置，然后通過一個與模擬電話網(wǎng)絡(luò)相連的語音網(wǎng)關(guān)發(fā)起請求呼叫。

SIP主要支持三種方式建立呼叫，包括：由用戶客戶機（UAC）直接向用戶服務(wù)器（UAS）發(fā)起的呼叫，由用戶客戶機在重定向服務(wù)器的協(xié)助下進(jìn)行的重定向呼叫和由服務(wù)器代表用戶客戶機向被叫發(fā)起呼叫。圖1是由SIP建立呼叫的模型。

3 SIP和H.323、XMPP協(xié)議的比較

SIP和H.323、XMPP協(xié)議都是作為多媒體通信的應(yīng)用層控信令協(xié)議設(shè)計的。H.323試圖用VOIP電話替換傳統(tǒng)的模擬通信，且只是傳輸方式由原來的電路交換變成了分組交換，就如同模擬傳輸變成數(shù)字傳輸。XMPP（可擴展通訊和表示協(xié)議）以Jabber協(xié)議為基礎(chǔ)，可用于服務(wù)類實時通訊、表示和需求響應(yīng)服務(wù)中的XML數(shù)據(jù)元流式傳輸。而SIP協(xié)議側(cè)重于將IP電話作為因特網(wǎng)上的一個應(yīng)用，相比較于較其它協(xié)議（如FTP，E-mail等），雖然都利用RTP作為媒體傳輸?shù)膮f(xié)議，但H.323是一個相對復(fù)雜的協(xié)議，增加了信令和QoS的要求。

H.323采用基于抽象語法標(biāo)記ASN.1和壓縮編碼規(guī)則的簡潔的二進(jìn)制編碼規(guī)則發(fā)送其各種形式的信息。XMPP是基于可擴展標(biāo)記語言（XML）的協(xié)議，它繼承了在XML環(huán)境中靈活的擴展性，因此，基于XMPP的應(yīng)用具有超強的可擴展性。而SIP以文本形式描述的協(xié)議，類似于HTTP?；谖谋镜木幋a協(xié)議，能夠顯而易見的表示其頭域的意義，如From、To、Subject等域名。過去的實踐，已經(jīng)充分證明了這種不需要復(fù)雜文檔說明的標(biāo)準(zhǔn)的優(yōu)越性。

在電話會議支持方面，由于H.323協(xié)議中規(guī)定由多點控制單元（MCU）集中控制會議各種功能，要求所有參加會議終端都將控制消息發(fā)送到MCU，MCU極有可能成為電話會議的瓶頸；另外H.323協(xié)議只支持信令的單播功能，而不支持組播功能，限制了協(xié)議的可擴展性，同時也降低了可靠性。雖然XMPP是支持組播的消息類型，但協(xié)議本身仍需為創(chuàng)建方便和高效的多人視頻會議進(jìn)行完善。而SIP協(xié)議設(shè)計之初就設(shè)立了分布式的呼叫機制，其組播功能不僅能夠便于會議控制，而且簡化了用戶的定位、邀請群組等，并且節(jié)約了寬帶的占用。

H.323中專門定義了用于增值業(yè)務(wù)的協(xié)議，比如H.450.1、H.450.2和H.450.3等。XMPP協(xié)議經(jīng)過擴展以后，可以通過發(fā)送擴展的信息來處理用戶的需求，以及在XMPP的頂端建立如內(nèi)容系統(tǒng)和基于地址的服務(wù)等應(yīng)用程序。同樣，SIP協(xié)議也可以非常方便地支持補充業(yè)務(wù)或智能業(yè)務(wù)。只要充分利用SIP已定義的方法和頭域，就可以輕松實現(xiàn)對這些業(yè)務(wù)的支持。對于無法通過現(xiàn)有的方法和頭域?qū)崿F(xiàn)的業(yè)務(wù)，因SIP本身就是一種可擴展的協(xié)議，所以也可以通過擴展特定的方法和頭域?qū)崿F(xiàn)相應(yīng)的智能業(yè)務(wù)，并在體系結(jié)構(gòu)中增加業(yè)務(wù)，提供一些補充服務(wù)或與智能網(wǎng)設(shè)備的接口。

在H.323中，呼叫建立過程涉及到三條信令信道的協(xié)調(diào)，呼叫建立所需的時間很長。XMPP使用訂閱協(xié)議管理多方通信中的帶內(nèi)通信（主要是多方數(shù)據(jù)通信），并為帶外多方通信提供基礎(chǔ)平臺。在SIP中，會話請求過程是和媒體信道協(xié)商過程等一起建立的。盡管第二版的H.323協(xié)議，已經(jīng)優(yōu)化了呼叫請求的過程，縮短了呼叫建立會話的時間，但仍無法與SIP只需要1.5個回路時延建立呼叫相提并論。并且，H.323的呼叫信令通道和H.245控制信道需要依賴可靠的傳輸協(xié)議。而SIP獨立于低層協(xié)議，一般使用UDP協(xié)議，通過利用自己信令層的可靠性機制來保證消息的可靠傳輸。

4 企業(yè)SIP電話設(shè)計方案

考慮SIP在企業(yè)網(wǎng)中的實際應(yīng)用，本文按照SIP協(xié)議規(guī)范提出了一套VOIP電話系統(tǒng)設(shè)計方案，SIP終端不僅可以在企業(yè)內(nèi)部網(wǎng)絡(luò)正常應(yīng)用，也可以透過企業(yè)防火墻借助互聯(lián)網(wǎng)進(jìn)行應(yīng)用，圖2其系統(tǒng)結(jié)構(gòu)示意圖。也就是說，企業(yè)IP電話網(wǎng)絡(luò)中使用私有地址的SIP終端可以作為被叫被外界SIP終端呼叫。這樣VOIP在企業(yè)網(wǎng)絡(luò)的應(yīng)用才有意義。

4.1 系統(tǒng)基本工作流程

用戶注冊：用戶通過客戶機自動向SIP服務(wù)器端發(fā)送注冊信息；該服務(wù)器的SIP注冊服務(wù)模塊接收注冊信息后，要先對客戶端進(jìn)行身份驗證，確認(rèn)其合法后再對該用戶的狀態(tài)信息、IP地址信息等進(jìn)行更新。

會話建立：用戶A準(zhǔn)備發(fā)起一次與用戶B通話時，首先A通過其用戶客戶機將會話請求傳至SIP服務(wù)器，之后通過該服務(wù)器進(jìn)一步查找用戶B的有關(guān)信息，并進(jìn)行精確定位，服務(wù)器判定用戶B是否具有接通能力，如果可以則將用戶A的呼叫請求直接轉(zhuǎn)發(fā)給用戶B，否則服務(wù)器直接向A返回拒絕信息。

通話過程：如果A和B之問的通信鏈路建立成功，則他們之間直接進(jìn)行通信直至?xí)捊Y(jié)束，通話結(jié)束時向服務(wù)器發(fā)送會話結(jié)束請求。

4.2 系統(tǒng)協(xié)議結(jié)構(gòu)

由于SIP僅是會話初始化協(xié)議，不能像H.323協(xié)議的通信系統(tǒng)那樣提供全部的語音會話業(yè)務(wù)，必須協(xié)同其他協(xié)議共同來建立一個完整的多媒體業(yè)務(wù)體系結(jié)構(gòu)，本方案采用的協(xié)議結(jié)構(gòu)如圖3。在應(yīng)用層，SIP協(xié)議主要負(fù)責(zé)會話的建立、管理以及性能協(xié)商等任務(wù)，由于SIP協(xié)議本身提供了可靠的響應(yīng)機制，故在傳輸層選用UDP協(xié)議也能保證信令的正確傳輸。實時流協(xié)議（RTSP）用于控制“一點到多點”的多媒體數(shù)據(jù)流。系統(tǒng)采用了資源預(yù)留協(xié)議（RSVP）和實時傳輸控制協(xié)議（RTCP），以確保系統(tǒng)具有較高的服務(wù)質(zhì)量。資源預(yù)留協(xié)議規(guī)定和分配了IP網(wǎng)絡(luò)的資源保護技術(shù)，可將資源預(yù)留給一個或多個給定的會話，并且該會話優(yōu)先于任何試圖參與雙方之間的其它媒體交換；實時傳輸控制協(xié)議用來檢測并潛在地解決發(fā)送問題，從而監(jiān)控會話質(zhì)量和檢測網(wǎng)絡(luò)問題以達(dá)到對QoS的監(jiān)控。

實時傳輸協(xié)議（RTP）用來實現(xiàn)端到端的語音數(shù)據(jù)的實時傳輸業(yè)務(wù)。由于使用UDP協(xié)議，得到了端到端的QoS支持，基于SIP協(xié)議的IP電話系統(tǒng)，在網(wǎng)絡(luò)帶寬被其它業(yè)務(wù)負(fù)載較重時，可以降低在超時連接時導(dǎo)致呼叫建立的延遲，因此本方案在傳輸層選用無狀態(tài)的UDP來傳送語音信息。這里以將RTP看作是在UDP協(xié)議上運行應(yīng)用服務(wù)，構(gòu)成支持實時數(shù)據(jù)傳遞所需的傳輸功能的不同部分。

5 國內(nèi)外SIP協(xié)議的應(yīng)用

自2000年6月，瑞典舉行的Voice On the Net 2000展示會以來，VOIP主流通信協(xié)議的發(fā)展和變化一直為人們所重點關(guān)注。

目前，采用H.323的VOIP服務(wù)對終端設(shè)備的要求較高。XMPP協(xié)議是IETF近期的標(biāo)準(zhǔn)，有待進(jìn)一步完善。而SIP協(xié)議優(yōu)勢非常明顯，它簡單靈活、分布控制，而且極易與其它服務(wù)集成。因此，在開發(fā)VOIP產(chǎn)品的同時，要關(guān)注SIP的發(fā)展，借鑒其有用之處。不可否認(rèn)，在整個電信網(wǎng)絡(luò)中，一直存在采用H.323協(xié)議統(tǒng)一VOIP實現(xiàn)的呼聲，不過，電信廠商和運營公司均承認(rèn)SIP的靈活性，并已采取行動利用SIP協(xié)議開發(fā)相關(guān)應(yīng)用產(chǎn)品。

微軟公司：早在2000年，微軟公司就推出了基于SIP協(xié)議的即時通信產(chǎn)品，經(jīng)過不斷優(yōu)化和升級，其最新的版本是LYNC 2013，LYNC 2013提供了在線狀態(tài)、即時消息、語音、視頻、WEB會議等功能，已經(jīng)占據(jù)了國際統(tǒng)一通信大部分市場。

AVAYA：從2004年就已經(jīng)開始著手基于SIP的產(chǎn)品及解決方案的研發(fā)，而Avaya在SIP上的定位也非常明確，所以在解決方案的規(guī)劃上，Avaya力求把SIP和原有的應(yīng)用層解決方案緊密融合。并在原有應(yīng)用的基礎(chǔ)上擴展由于SIP的引入而增加的新的功能。CCS服務(wù)器是Avaya最新的SIP服務(wù)集成解決方案，CCS服務(wù)器集成了SIP中幾乎所有的主要服務(wù)器功能，為企業(yè)基于SIP的通信網(wǎng)絡(luò)提供集成的服務(wù)。

華為公司：近年來，華為公司認(rèn)為隨著基于SIP的VoIP實現(xiàn)門檻越來越低，語音業(yè)務(wù)將逐步退出主導(dǎo)地位，成為一種最基本的業(yè)務(wù)。因此，華為公司不僅僅了基于SIP的語音網(wǎng)關(guān)產(chǎn)品，如：迅時MX51系列語音網(wǎng)關(guān)；還推出了基于SIP的融合通信產(chǎn)品eSpace。

篇3

中圖分類號：TN915.04 文獻(xiàn)標(biāo)識碼：A文章編號：1007-9599 (2011) 09-0000-01

SIP Protocol and Application Analysis in The IMS

Zheng Zhijun

(China Tietong Telecommunications Corporation,Hengshui Branch,Hengshui053000,China)

Abstract:IMS is a 3GPP Release 5 version of the proposed support for IP Multimedia Subsystem services,SIP is an application layer control protocol for creating,modifying and terminating one or many of the multimedia sessions,SIP is the basic control of IMS agreement.This paper briefly describes IMS and SIP protocol,SIP protocol and then introduce the basic IMS applications and extended application.

Keywords:SIP;IMS;Application

一、SIP介紹

SIP（Session Initiation Protocol）是一個會話層的信令控制協(xié)議，它獨立于底層協(xié)議，用于建立、修改和終止IP網(wǎng)上的雙方或多方的多媒體會話。1999年由IETF組織提出，它是一個在基于IP網(wǎng)絡(luò)中，實現(xiàn)實時通信應(yīng)用的一種協(xié)議。SIP支持、重定向、登記定位用戶等功能，支持用戶移動，與RTP/RTCP、SDP、RTSP、DNS等協(xié)議配合，可支持和應(yīng)用于語音、視頻、數(shù)據(jù)等多媒體業(yè)務(wù)，同時可以應(yīng)用于presence（呈現(xiàn)）、instant message（即時消息）等特色業(yè)務(wù)。它的應(yīng)用非常靈活。

SIP有下面五個基本功能：

（一）確定用戶位置：確定被叫SIP用戶所在的位置。SIP的最強大之處就是用戶定位功能，它可以利用SIP終端在注冊服務(wù)器上的注冊信息實現(xiàn)用戶定位，也可以利用其他定位服務(wù)器，如DNS、LDAP等提供的定位服務(wù)來增強其定位功能。

（二）確定用戶可用性：確定被叫會話終端是否可以參加此會話。SIP支持多種地址描述和尋址方式，包括SIP-URI、Tel-URL和SIPS-URI。這樣，SIP主叫根據(jù)被叫地址，就可以識別出被叫是否在傳統(tǒng)電話網(wǎng)上，然后通過一個與傳統(tǒng)電話網(wǎng)相連的網(wǎng)關(guān)向被叫發(fā)起并建立呼叫。

（三）確定用戶能力：確定被叫終端可用于參加會話的媒體類型及媒體參數(shù)。SIP終端在消息交互過程中攜帶自身的媒體類型和媒體參數(shù)，這使得會話雙方都可以明確對方的會話能力。

（四）建立會話：建立主被叫雙方的會話。SIP會話雙方通過協(xié)商媒體類型和媒體參數(shù)，最終選擇雙方都具有的能力建立起會話。

（五）管理會話：可以更改會話參數(shù)或中止會話。SIP本身已經(jīng)從最初致力于P2P通信發(fā)展成為了下一代網(wǎng)絡(luò)（NGN）綜合協(xié)議體系的核心。

二、IMS系統(tǒng)

IMS（IP Multimedia Subsystem）是IP多媒體子系統(tǒng)，本質(zhì)上說是一種網(wǎng)絡(luò)結(jié)構(gòu)。核心思想是在3G核心網(wǎng)中支持多媒體會話及其他基于SIP協(xié)議的業(yè)務(wù)，目的將蜂窩移動通信和互聯(lián)網(wǎng)技術(shù)結(jié)合起來，能提供綜合業(yè)務(wù)的下一代通信網(wǎng)絡(luò)，它獨立于接入和承載技術(shù)，即IMS的核心特點是采用SIP協(xié)議和與接入的無關(guān)性。

三、SIP協(xié)議在IMS中的應(yīng)用

IMS的主要功能實體包括呼叫/會話功能實體（CSCF）、原籍用戶服務(wù)器（HSS）、媒體網(wǎng)關(guān)控制實體（MGCF）和媒體網(wǎng)關(guān)（MGW）等。其中最重要的實體是CSCF和HSS。CSCF主要負(fù)責(zé)對多媒體會話進(jìn)行處理，其功能包括多媒體會話控制、地址翻譯以及對業(yè)務(wù)協(xié)商進(jìn)行服務(wù)轉(zhuǎn)換等，相當(dāng)于SIP服務(wù)器。CSCF分為CSCF（P-CSCF）、查詢CSCF（I-CSCF）和服務(wù)CSCF（S-CSCF）。P-CSCF是IMS系統(tǒng)中用戶的第一個接觸點，所有的SIP信令都必須通過P-CSCF。I-CSCF提供到歸屬網(wǎng)絡(luò)的入口，將歸屬網(wǎng)絡(luò)的拓?fù)潆[藏起來，并可通過歸屬用戶服務(wù)器HSS靈活選擇S-CSCF，并將SIP信令路由到S-CSCF。S-CSCF是IMS的核心，它位于歸屬網(wǎng)絡(luò)，提供UE會話控制和注冊服務(wù)。在SIP會話中他是SIP的服務(wù)器。HSS類似于現(xiàn)在移動網(wǎng)絡(luò)的HLR，它是IMS中所有與用戶和服務(wù)相關(guān)的數(shù)據(jù)的主要存儲器。存儲在HSS中的數(shù)據(jù)主要包括用戶身份、注冊信息、接入?yún)?shù)和服務(wù)觸發(fā)信息等。

SIP信令消息從移動用戶發(fā)起，經(jīng)UMTS（通用移動通信系統(tǒng)）陸地?zé)o線接入網(wǎng)絡(luò)進(jìn)入核心網(wǎng)，通過SGSN（GPRS服務(wù)支持節(jié)點）和GGSN（GPRS網(wǎng)關(guān)支持節(jié)點）到達(dá)CSCF，經(jīng)過處理后送往其他IMS網(wǎng)絡(luò)、MGCF/MGW網(wǎng)絡(luò)或外部IP網(wǎng)絡(luò)。在此過程中，SGSN和GGSN僅查看消息的目的IP地址，不分析消息的內(nèi)容，起到路由器的作用。

當(dāng)3GPP RS在規(guī)劃IMS時，由于SIP的靈活性和可擴展性，決定采用SIP機制作為IMS網(wǎng)絡(luò)的會話初始化協(xié)議。3G網(wǎng)絡(luò)被分為3個不同的域：電路交換域、分組交換域和IP多媒體交換域。其中IP多媒體子系統(tǒng)域是3G中最重要的域，這個域采用SIP作為主要的信令協(xié)議向用戶提供基于因特網(wǎng)的多媒體服務(wù)。從邏輯上講，所有的3G終端都包含一個SIP用戶，IP多媒體網(wǎng)絡(luò)節(jié)點就是SIP規(guī)范中所提到的。

篇4

一、前言

隨著企業(yè)生產(chǎn)自動化程度不斷加深，管理效率不斷上升，企業(yè)逐步由分層管理向扁平化管理轉(zhuǎn)變。而伴隨著企業(yè)管理方式的轉(zhuǎn)變，企業(yè)通信系統(tǒng)也開始向融合智能化發(fā)展。這是因為傳統(tǒng)的有線對講系統(tǒng)、調(diào)度系統(tǒng)、廣播系統(tǒng)、監(jiān)控系統(tǒng)等是多個獨立的系統(tǒng)，其重復(fù)布網(wǎng)、維護復(fù)雜等問題無法有效得到解決。為了解決這些問題，首先需要將這些系統(tǒng)統(tǒng)一到一個網(wǎng)絡(luò)中來，然后通過一個系統(tǒng)將用戶使用的電話、對講等語音終端進(jìn)行管理。管理大容量的語音終端比較成熟的是軟交換技術(shù)，同時可以發(fā)揮網(wǎng)絡(luò)靈活接入的特點，完成各種系統(tǒng)統(tǒng)一接入的要求。

二、問題提出

傳統(tǒng)的語音通信系統(tǒng)主要包括調(diào)度系統(tǒng)、有線對講系統(tǒng)、應(yīng)急通信系統(tǒng)等利用程控技術(shù)設(shè)計出不同操作模式的語音交換系統(tǒng)。這些系統(tǒng)由于主機與終端的差異導(dǎo)致骨干網(wǎng)絡(luò)無法共用，導(dǎo)致運維復(fù)雜等?，F(xiàn)在主流的語音交換技術(shù)為軟交換技術(shù)，而軟交換技術(shù)最為靈活的協(xié)議為SIP協(xié)議簇。但是SIP協(xié)議簇主要定義了終端基本的注冊、呼叫、應(yīng)答等基本狀態(tài)內(nèi)容，對于設(shè)備終端的屬性及過程控制沒有進(jìn)行詳細(xì)定義，因此導(dǎo)致了各個廠家SIP協(xié)議簇擴展內(nèi)容的大不相同。在IP調(diào)度系統(tǒng)中，不同設(shè)備間交互的協(xié)議種類多，導(dǎo)致不同廠商的調(diào)度控制終端和軟交換服務(wù)器間不能通用。如果通過擴展標(biāo)準(zhǔn)SIP協(xié)議簇來實現(xiàn)IP調(diào)度系統(tǒng)功能，并且簡化IP調(diào)度系統(tǒng)協(xié)議種類，讓不同IP調(diào)度系統(tǒng)設(shè)備廠商的設(shè)備實現(xiàn)通用。這將改變目前用戶對多種網(wǎng)關(guān)設(shè)備無法統(tǒng)一管理的現(xiàn)狀。傳統(tǒng)設(shè)備不同操作模式的語音通信系統(tǒng)便可在同一軟交換上實現(xiàn)。

三、擴展協(xié)議設(shè)計

基于IP的工業(yè)綜合通信系統(tǒng)是標(biāo)準(zhǔn)軟交換系統(tǒng)融合了調(diào)度、對講系統(tǒng)特點在工業(yè)領(lǐng)域應(yīng)用特點，通過對RFC3621的SIP協(xié)議簇進(jìn)行補充實現(xiàn)的。標(biāo)準(zhǔn)的軟交換系統(tǒng)設(shè)計了終端用戶的管理、交換管理、狀態(tài)管理等基本管理，調(diào)度系統(tǒng)系統(tǒng)則需要提供強插、強拆、監(jiān)聽、摘掛機狀態(tài)、會議等等特殊功能。（圖1）

SIP請求消息分為請求行、.消息頭域及消息體三部分。消息頭域中包含許多個消息頭，分別攜帶著IP終端的各種信息。將在SIP請求消息的消息頭域中加入自定義的消息頭。增加的消息頭表示調(diào)度控制終端需要讓軟交換服務(wù)器執(zhí)行的調(diào)度功能。在消息頭后加入需要參與該調(diào)度功能的話機號碼。同時預(yù)留一個區(qū)域，供用戶傳送備用信息，如設(shè)備相關(guān)的型號，協(xié)議的版本等。當(dāng)然自定義消息頭遵從標(biāo)準(zhǔn)的SIP協(xié)議消息頭格式，能夠和標(biāo)準(zhǔn)的SIP消息頭用相同的方法封裝和解析，最終形成一個具有自定義消息頭的SIP請求消息。

四、系統(tǒng)實際應(yīng)用

基于SIP協(xié)議簇擴展的應(yīng)用在企業(yè)通信系統(tǒng)中最為常見，如調(diào)度系統(tǒng)、有線對講系統(tǒng)、廣播系統(tǒng)等。但是各種語音通信系統(tǒng)的操作模式不同，導(dǎo)致SIP協(xié)議簇擴展信息的結(jié)構(gòu)及內(nèi)容的不同。

基于軟交換的調(diào)度系統(tǒng)，主要功能是完成電話終端的兩方通話、三方通話、強插、強拆等等功能。協(xié)助調(diào)度系統(tǒng)完成這些功能的終端叫調(diào)度臺。調(diào)度臺通過標(biāo)配的鍵權(quán)電話來操作調(diào)度臺，完成各項功能的實現(xiàn)。

當(dāng)鍵權(quán)電話提機后，可操作鍵盤發(fā)送鍵權(quán)電話的操作指令。該指令的結(jié)構(gòu)為：

長度是對整個信息長度一個說明，保證信息的完整性；鍵盤編號進(jìn)行多鍵盤的區(qū)分；命令是不同操作功能的標(biāo)識，命令主要是強插、強拆、三方通話、監(jiān)聽等等；包標(biāo)識符是對本信息包類型進(jìn)行說明，包標(biāo)示符主要標(biāo)注請求（REQUEST），回應(yīng)（RESPONSE），事件通知（EVENT），命令（COMMAND）四種；序列號用來標(biāo)識一次請求和回應(yīng)；結(jié)束符標(biāo)識說明本命令執(zhí)行完畢結(jié)束；數(shù)據(jù)包內(nèi)容是實際的內(nèi)容。

例如：鍵權(quán)話機提機通過鍵盤向軟交換提出呼叫一個用戶的命令，首先構(gòu)造一個INVITE請求，并把鍵盤發(fā)送的操作指令嵌入到協(xié)議中，然后這個請求會由Proxy層層轉(zhuǎn)發(fā)，最后到達(dá)一個或者多個可能處理這個邀請的UAS，即調(diào)度服務(wù)器。一旦調(diào)度服務(wù)器收到這個消息并進(jìn)行處理，那么通過發(fā)送2XX進(jìn)行應(yīng)答，如果拒絕則發(fā)送其他相應(yīng)的標(biāo)準(zhǔn)SIP拒絕協(xié)議。這樣，鍵盤通過發(fā)送擴展的sip協(xié)議完成對多個終端的控制，完成用戶的調(diào)度功能需求。

另外，擴展SIP協(xié)議同樣可以應(yīng)用在有線對講系統(tǒng)中。對講系統(tǒng)主要功能特點是按鍵呼叫，松鍵終止語音，同時向相關(guān)崗位傳送本機的工作狀態(tài)。那么主要將本機狀態(tài)發(fā)送到對講主機，然后由主機向相關(guān)終端發(fā)送消息以便顯示與之相關(guān)的終端狀態(tài)。主要在包標(biāo)識符中增加一個狀態(tài)（STATE），然后在數(shù)據(jù)包內(nèi)容中標(biāo)識本機號碼即可。

通過擴展SIP協(xié)議簇實現(xiàn)的基于軟交換的調(diào)度系統(tǒng)、有線對講系統(tǒng)功能在工業(yè)現(xiàn)場得到了廣泛的應(yīng)用。解決了工業(yè)語音網(wǎng)融合的問題，為用戶設(shè)計整個企業(yè)的網(wǎng)絡(luò)提供了技術(shù)保障。

篇5

引言

目前傳統(tǒng)的公眾交換電話網(wǎng)（PSTN）上傳送著許多數(shù)據(jù)業(yè)務(wù)，由于快速增長的數(shù)據(jù)業(yè)務(wù)給并不適合傳送數(shù)據(jù)業(yè)務(wù)的電話網(wǎng)造成了很大的壓力。因此，基于分組技術(shù)的數(shù)據(jù)網(wǎng)與電路交換網(wǎng)最終必將走向融合，產(chǎn)生下一代由業(yè)務(wù)驅(qū)動的網(wǎng)絡(luò)。軟交換是下一代網(wǎng)絡(luò)交換的核心，如果說傳統(tǒng)電信網(wǎng)絡(luò)是基于程控交換機的網(wǎng)絡(luò)，而下一代網(wǎng)絡(luò)則是基于軟交換的網(wǎng)絡(luò)。

1系統(tǒng)開發(fā)的技術(shù)基礎(chǔ)

1.1軟交換的概念

我國信息產(chǎn)業(yè)部電信傳輸研究所對軟交換的定義是：“軟交換是網(wǎng)絡(luò)演進(jìn)以及下一代分組網(wǎng)絡(luò)的核心設(shè)備之一，它獨立于傳送網(wǎng)絡(luò)，主要完成呼叫控制、資源分配、協(xié)議處理、路由、認(rèn)證、計費等主要功能，同時可以向用戶提供現(xiàn)有電路交換機所能提供的所有業(yè)務(wù)，并向第三方提供可編程能力?！?/p>

1.2 SIP協(xié)議介紹

會話初始化協(xié)議SIP（Session Initiation Protocol）是一個面向Internet 會議和電話的簡單信令協(xié)議，SIP最初由IETF MMUSIC (Multiparty Multimedia Session Control) 工作組提出。它的主要目的是為了解決IP網(wǎng)中的

信令控制，以及同軟交換機的通信，從而構(gòu)成新一代的通信平臺。

2 系統(tǒng)的總體設(shè)計和實現(xiàn)

2.1系統(tǒng)的層次結(jié)構(gòu)

軟交換采用業(yè)務(wù)與交換分離的設(shè)計思想，在系統(tǒng)設(shè)計結(jié)構(gòu)上將軟交換技術(shù)應(yīng)用設(shè)計為三層結(jié)構(gòu)，底層為用戶接入層，中間為交換支撐層，最上面是業(yè)務(wù)實現(xiàn)層。系統(tǒng)的層次結(jié)構(gòu)如圖1所示。

2.2呼叫管理服務(wù)器的設(shè)計與實現(xiàn)

呼叫管理服務(wù)器處于該體系結(jié)構(gòu)中的網(wǎng)絡(luò)控制層，它是軟交換系統(tǒng)的核心部分。呼叫管理服務(wù)器除了完成呼叫控制、連接控制和協(xié)議處理功能外，還將提供原來由網(wǎng)守設(shè)備提供的資源管理、路由以及認(rèn)證、計費等功能。

軟交換系統(tǒng)的運行需要SIP協(xié)議棧和SDP協(xié)議棧?？蛻舳藨?yīng)該能夠產(chǎn)生INVITE和ACK請求，能夠產(chǎn)生和解析Call-ID，Content-Length，Content-Type，Cseq，F(xiàn)rom和To頭部字段。呼叫管理服務(wù)器應(yīng)該能夠接收INVITE，ACK，BYE，CANCEL和REGISTER請求，應(yīng)該能夠產(chǎn)生和解析Call-ID，Content-Length，Content-Type，Cseq，Expires，F(xiàn)rom，Max-Forwards，Via和To頭部字段。為了能夠使客戶端和服務(wù)端能夠使用RTP傳輸語音流，SDP協(xié)議應(yīng)該能夠產(chǎn)生和解析v，o，s，c，t，m和a頭部字段。

本系統(tǒng)以面向?qū)ο蟮姆椒ㄔO(shè)計了一個滿足系統(tǒng)要求的最小SIP和SDP協(xié)議棧。SIP協(xié)議棧支持INVITE，ACK，BYE，REGISTER和CANCEL請求，支持100，180，200，300，400，500和600狀態(tài)應(yīng)答，支持Subject，Contact，Call-ID，Content-Length，Content-Type，Cseq，Expires，F(xiàn)rom，Max-Forwards，Via和To頭部字段。SDP協(xié)議棧支持v，o，s，c，t，m和a頭部字段。SIP和SDP中的頭部字段都是以類的形式實現(xiàn)的，所支持的頭部字段都是從一個抽象類Header繼承而來。抽象類Header的定義如下：

class Header

{

public:

Header();

virtual ~Header() = 0;

virtual string encode() const = 0;

virtual void decode(const string& headerString) = 0;

virtual string getName() const = 0;

};

其中最主要的方法為decode，主要用來對相應(yīng)的頭部字段進(jìn)行解析，getName方法返回當(dāng)前的頭部字段類的類名，encode方法用來產(chǎn)生相應(yīng)的頭部字段的字符串。

其中SIP協(xié)議棧的結(jié)構(gòu)如圖2所示：

解析層是對SIP消息進(jìn)行解析和構(gòu)造。解析層實現(xiàn)的關(guān)鍵在于各個頭部字段類的設(shè)計及其相應(yīng)decode方法的實現(xiàn)。解析層的實現(xiàn)借鑒了VOCAL開放源碼中SipStack的頭部字段類的設(shè)計方法，VOCAL的SipStack對RFC2543完全支持，但協(xié)議棧非常的龐大，設(shè)計的過程中參考了VOCAL的SipStack的頭部字段類的設(shè)計形式實現(xiàn)了一個簡潔，實用的SIP協(xié)議棧，SIP協(xié)議棧的大小還不到VOCAL的SipStack的1/10。

3 結(jié)束語

總之，基于SIP協(xié)議軟交換系統(tǒng)的前景非常廣闊，在這個領(lǐng)域，有許多技術(shù)難題等待人們?nèi)ソ鉀Q。相信在大家的共同推動之下，軟交換系統(tǒng)的應(yīng)用將得到快速的發(fā)展。

參考文獻(xiàn)

[1]強磊等編著.基于軟交換的下一代網(wǎng)絡(luò)組網(wǎng)技術(shù)[M].人民郵電出版社，2005

篇6

中圖分類號：TP393.0

文獻(xiàn)標(biāo)識碼：A

DOI： 10.3969/j.issn.1003-6970.2015.07.025

0 SIP簡介

SIP（會話初始協(xié)議，RFC3261）是IETF定義的通過IP網(wǎng)絡(luò)建立和管理多媒體會話的協(xié)議，它采用的是眾所周知的客戶機服務(wù)器模式，它借鑒了SMTP（簡單郵件傳送協(xié)議，RFC2821）以及HTTP（超文本傳送協(xié)議，RFC2616）的原理，而這兩個協(xié)議是因特網(wǎng)上最成功的協(xié)議，同時，SIP是一個基于文本的協(xié)議，這意味著它更易于擴展、糾錯和構(gòu)建各種業(yè)務(wù)。因此，在IMS（IP多媒體子系統(tǒng)）中，選擇SIP作為其會話控制協(xié)議，更易于建立具有更大承載能力的業(yè)務(wù)。

根據(jù)協(xié)議標(biāo)準(zhǔn)定義及實際研制經(jīng)驗，協(xié)議平臺的SIP協(xié)議分析劃分為以下幾部分內(nèi)容： SIP事務(wù)用戶層（TU，Transaction User），事務(wù)層（TR，TRansaction），傳輸層（TP，TransPort），編解碼模塊（SIP PARSER/SDPPARSER，SIP協(xié)議編解碼及SDP編解碼），信令壓縮模塊（SIGCOMP）幾個協(xié)議主體部分。除了這幾個協(xié)議主體以外，SIP還需要實現(xiàn)和上層業(yè)務(wù)、數(shù)據(jù)庫以及底層承載之間的接口，方便進(jìn)行數(shù)據(jù)以及消息的交互。

SIP協(xié)議的TU層是SIP協(xié)議主體的重要組成部分，它的功能包含幾個方面：（1）負(fù)責(zé)SIP消息到上層應(yīng)用進(jìn)程的消息分發(fā)；對上層應(yīng)用屏蔽底層協(xié)議實現(xiàn)和分布式處理的細(xì)節(jié)；（2）對于需要創(chuàng)建對話的，維護對話的生命周期，管理對話的事務(wù)列表；（3）完成UAC， UAS或者pro xy的協(xié)議棧行為。

SIP采用的是一種offer/answer模型來描述會話。一個UA發(fā)起一個會話描述，稱為offer，另一個UA以另一個會話描述來進(jìn)行響應(yīng)則為answer，一個offer/answer在一個Dialog上下文中進(jìn)行交互，因為在具體實現(xiàn)SIP協(xié)議棧時，TU需要建立數(shù)據(jù)區(qū)來維護對話Dialog的相關(guān)信息，如圖1所示，TU是通過建立leg模型來維護dialog的，TU建立的數(shù)據(jù)區(qū)稱作leg，leg將會保存對于會話創(chuàng)建、會話釋放，處理請求、處理響應(yīng)所需要的一些關(guān)鍵信息，而這些信息是通過SIP消息從相應(yīng)的頭部中進(jìn)行提取，和會話相關(guān)的主要頭部From，To以及Call-ID中的信息將都會保存在leg中。

數(shù)據(jù)區(qū)的創(chuàng)建根據(jù)協(xié)議棧的行為分為UA和proxy兩種情況。

Proxy方式下會存在一人一出兩個Leg對象，人呼側(cè)由TU收到事務(wù)層的初始請求而創(chuàng)建人呼側(cè)Leg對象，消息通過人呼側(cè)Leg處理后上報上層應(yīng)用，上層應(yīng)用處理結(jié)束后，轉(zhuǎn)發(fā)初始請求到TU的出呼側(cè)，TU進(jìn)而創(chuàng)建出呼側(cè)Leg對象以及下發(fā)SIP消息。

UA方式下，作為被叫網(wǎng)元，TU協(xié)議棧收到事務(wù)的初始請求后，創(chuàng)建人呼Leg后，通過初始請求消息上報上層業(yè)務(wù)，上層業(yè)務(wù)處理完業(yè)務(wù)邏輯后，通過人呼Leg回送響應(yīng)到事務(wù)層。后續(xù)請求和響應(yīng)都是通過人呼Leg傳送。作為主叫網(wǎng)元，上層應(yīng)用調(diào)用發(fā)送初始請求接口到TU，TU創(chuàng)建出呼側(cè)Leg后，初始請求消息通過該Leg發(fā)送至事務(wù)層，后續(xù)請求和響應(yīng)都是通過出呼側(cè)Leg傳遞。

1 forking功能

fork即常說的分叉，一個請求可以分叉為發(fā)往多個目標(biāo)地址的請求。假定B用戶為一號多機用戶，即一個SIP用戶可以同時在很多終端上注冊，每種終端可以實現(xiàn)不同的功能，比如便攜PC支持視頻而固定SIP電話可能功能簡潔，B用戶多個終端同時在線，當(dāng)A用戶呼叫B用戶時，那么B用戶的多個終端都會收到呼叫請求，它的任意終端都可以去響應(yīng)這個呼叫。A最終會選擇一個終端創(chuàng)建會話。

在IMS中實現(xiàn)fork功能涉及到的網(wǎng)元類型分為終端（UA行為）以及服務(wù)器（proxy）行為，根據(jù)協(xié)議的描述，梳理不同網(wǎng)元的處理原則。

1.1 終端處理原則

（1）請求

根據(jù)協(xié)議的描述，只有初始對話（獨立事務(wù)）請求才會發(fā)生fork。終端可以在初始請求INVITE的碼流中的通過添加Request-Disposition頭部中指示進(jìn)行fork的相關(guān)處理。同時，當(dāng)被叫終端注冊了多個時，主叫終端可以添加Accept-Contact，Reject-Contact參數(shù)，指示選擇符合用戶偏好的被叫以及優(yōu)先級更高的被叫。

（2）響應(yīng)

當(dāng)fork發(fā)生時，多個被叫終端都會對主叫產(chǎn)生響應(yīng)，未創(chuàng)建對話前，主叫終端可以接受或拒絕任何被叫終端的Fork應(yīng)答，如果終端拒絕fork臨時應(yīng)答，那么必須發(fā)送cancel或者bye請求，這些請求是針對每個終端即每一個fork的分支都需要發(fā)出。

主叫終端如果接收到被叫終端一個fork分支的成功應(yīng)答即2xx響應(yīng)，開始創(chuàng)建會話；應(yīng)該釋放其他fork分支的早對話和非早對話，具體釋放的方式根據(jù)各個fork分支的不同而不同。其中對于已經(jīng)收到了臨時響應(yīng)的fork分支，不管是否建立起了早對話，則發(fā)送CANCEL請求來釋放；對于沒有收到任何的臨時響應(yīng)的fork分支，則不能發(fā)送CANCEL請求，通過TU設(shè)置的保護定時器超時，來釋放該分支的相關(guān)資源。

主叫終端只能收到一條最終響應(yīng)，如果收到2xx響應(yīng)，則建立對話，如果為2xx以上的響應(yīng)，則認(rèn)為無法建立呼叫，則需要釋放呼叫。

1.2 處理原則

（1）請求

提取碼流中fork和用戶喜好相關(guān)的字段，處理fork請求，比如到被叫的歸屬的服務(wù)器，需要將初始INVITE請求分叉為多個發(fā)送到被叫終端，對于非初始請求，需要進(jìn)行轉(zhuǎn)發(fā)。

（2）響應(yīng)

立即轉(zhuǎn)發(fā)除100（Trying）以外的任何臨時響應(yīng)。立即轉(zhuǎn)發(fā)能成功建立對話的第一條2xx成功響應(yīng)，如果其中任意一個地址接收呼叫，該網(wǎng)絡(luò)服務(wù)器應(yīng)該向其它地址發(fā)送CANCEL消息，如果由于網(wǎng)絡(luò)時延而導(dǎo)致在服務(wù)器接收到多個200消息，服務(wù)器應(yīng)當(dāng)將后續(xù)的200消息拒絕掉，不應(yīng)當(dāng)后向轉(zhuǎn)發(fā)，這樣能保證只有一個終端能夠建立對話。

對于3xx類以上的非成功響應(yīng)，根據(jù)響應(yīng)碼的具體含義進(jìn)行處理，比如3xx需要優(yōu)先傳到主教終端進(jìn)行重定向，而對于4xx、5xx、6xx等非成功相應(yīng)，即先保存這些響應(yīng)，如果最后沒有收到任何2xx響應(yīng)，則根據(jù)協(xié)議規(guī)定的優(yōu)選的原則選擇響應(yīng)碼發(fā)送到主叫終端，結(jié)束整個會話。

2 SIP中fork的實現(xiàn)原理

SIP協(xié)議實現(xiàn)fork的基本邏輯功能：包括fo rk呼叫狀態(tài)維護，管理多個臨時響應(yīng)創(chuàng)建的對話，并在會話創(chuàng)建之前維持多個早對話出/人呼側(cè)消息的正確關(guān)聯(lián)關(guān)系。上層業(yè)務(wù)維護多個Contact的上下文與分叉呼叫之間的關(guān)系，分別對早對話進(jìn)行承載控制。

2.1 確定是否發(fā)生fork

當(dāng)被叫終端注冊了多個Contact地址時，SIP協(xié)議需要去提取碼流中的相關(guān)字段，通過Accept-Contact，Reject-Contact參數(shù)確定好被叫目標(biāo)集，并按照優(yōu)先級將多個被叫終端進(jìn)行排序，進(jìn)一步的提取Request-Disposition頭部的關(guān)鍵信息，對是否需要進(jìn)行fork進(jìn)行確定，該頭部的內(nèi)容如下：

proxy-directive=”proxy”

fork-directive="fork"/"no-fork"

parallel-directive="parallel"/"sequential"

其中proxy-directive確定當(dāng)前的網(wǎng)元是否為proxy，fork-directive是用來指示是否需要fork，當(dāng)指示為”no-fork”時，雖然被叫有多個，但是初始請求只會發(fā)送給優(yōu)先級最高的被叫終端并不會產(chǎn)生分叉，如果指示為”fork”時，則進(jìn)一步的讀取parallel-directive指示的值，parallel-directive若為“parallel”為并行fork，并行fork則需要被叫歸屬的服務(wù)器將初始的INVITE請求同時發(fā)送給多個被叫終端，既并行呼叫；若為“sequential”為串行fork，串行fork則不需要服務(wù)器將初始請求同時發(fā)送給多個被叫終端，而是逐個的發(fā)送，先發(fā)給第一個優(yōu)先級最高的被叫，如果接通，則不需要進(jìn)行后續(xù)處理，如果沒有成功接續(xù)，則繼續(xù)發(fā)送給第二個被叫，依次類推。

2.2 TU中會話的維護

從前面SIP的簡介我們得知，TU需要去維護會話dialog，而對于dialog的維護，TU需要創(chuàng)建數(shù)據(jù)區(qū)Leg去保存相應(yīng)的信息，fork情況下，可能存在同時發(fā)起多路fork分支的呼叫，而多個被叫終端的對話信息是不完全相同的，如果把所有的信息都保存在簡單情況下的一個Leg數(shù)據(jù)區(qū)里，則容易引起一些誤操作，邏輯很不清楚，所以，可以采用TU維護多對數(shù)據(jù)區(qū)的方式來解決。

普通呼叫情況下，SIP的TU層只需要維護人呼側(cè)和出呼側(cè)的一對Leg即可，這樣所有的消息都通過這一對Leg來進(jìn)行關(guān)鍵信息的記錄以及轉(zhuǎn)發(fā)。而fork情況下，由于終端有多個，而每個終端都可以傳送不同的請求和響應(yīng)到主叫終端，為了對每個終端的信息進(jìn)行彼此獨立的進(jìn)行保存，TU為每一個終端建立對應(yīng)的數(shù)據(jù)區(qū)Leg，具體如圖2所示，圖2和圖1比較可以看出，fork情況下，TU的人呼側(cè)和出呼側(cè)分別有多個Leg，而且人呼側(cè)和出呼側(cè)是一一對應(yīng)的，比如In Leg（0）和Out Leg（0）是對應(yīng)第一個被叫終端，用來記錄第一個別叫終端和主叫之間的會話信息，并進(jìn)行這一分支呼叫的消息轉(zhuǎn)發(fā)，而In Leg（l）和Out Leg（l）是為主叫終端和第二個被叫終端服務(wù)的。當(dāng)然，不管是fork的第一個分支還是第二個分支和主叫發(fā)生聯(lián)系，這都是屬于當(dāng)前的這一個完整的會話，因此兩路分支之間也可能有信息的交互，此時可以通過CALL這樣的一個空間來保存兩者的數(shù)據(jù)區(qū)索引，方便通過一個人呼叫的Leg能很快的訪問到另一個分支的Leg。

3 具體流程

SIP的具體流程要分為并行和串行兩種情形，分別進(jìn)行介紹：

3.1 并行流程

在并行流程中主叫的請求會同時被發(fā)送給兩個別叫用戶，具體流程如圖3所示，其中User AgentA為主叫用戶，User Agent B，C為被叫用戶，Proxy Server是IMS系統(tǒng)中的某個具體的網(wǎng)元，是服務(wù)器，主要是起到消息轉(zhuǎn)發(fā)以及完成fork功能的作用。

各步驟的具體含義如下：

主叫用戶A發(fā)起請求INVITE到服務(wù)器，對應(yīng)圖上消息（1）；

假定此服務(wù)器是被叫歸屬地的網(wǎng)元，它能檢測到有多個被叫聯(lián)系contact地址，同時通過Request-Disposition確定為發(fā)生并行fork，于是，向兩個被叫用戶B和C發(fā)起INVITE請求，對應(yīng)圖上消息（2）和（3）；

兩個被叫用戶收到INVITE請求后，提示用戶并振鈴，都發(fā)送180（ Ringing）消息通過服務(wù)器傳給主叫用戶，主叫用戶能同時聽到兩個被叫的回鈴音，對應(yīng)圖上消息（4）（5）（6）（7），此時，兩路別叫的180消息中的To頭部的tag值是不一樣的，這樣服務(wù)器中實現(xiàn)SIP的TU層就可以維護兩個leg，來保存兩路的不同會話信息；

兩個被叫用戶都會送響應(yīng)，上圖中被叫用戶B接通呼叫，產(chǎn)生2000K的應(yīng)答，而被叫用戶C則回送4XX消息，顯示忙，服務(wù)器接收到兩個被叫的不同應(yīng)答，需要進(jìn)行處理，它主動地對被叫用戶C回送ACK，以結(jié)束被叫用戶C之間的呼叫，同時將被叫用戶B的200 OK轉(zhuǎn)發(fā)到主叫側(cè)，具體對應(yīng)圖上的（8）（9）（10）（11）；

主叫收到成功響應(yīng)后，回送ACK消息到被叫用戶B予以證實，呼叫建立，對應(yīng)圖上的（12）和（13）；

主叫掛機，發(fā)送BYE消息，被叫回應(yīng)200 0K響應(yīng)，整個通話結(jié)束，對應(yīng)圖上的（14）（15）（16）（17）。

3.2 串行流程

在并行流程中主叫的請求會按照優(yōu)先級先后發(fā)送給兩個被叫用戶，具體流程如圖4所示：

各步驟的具體含義如下：

主叫用戶A發(fā)起請求INVITE到服務(wù)器，對應(yīng)圖上消息（1）；

假定此服務(wù)器是被叫歸屬地的網(wǎng)元，它能檢測到有多個被叫聯(lián)系co ntact地址，同時通過Request-Disposition確定為發(fā)生串行fork，就需要根據(jù)兩個被叫用戶的優(yōu)先級，優(yōu)先級通過Accept-Contact，Reject-Contact等參數(shù)按照RFC3841協(xié)議規(guī)定的原則進(jìn)行權(quán)值的計算，假定用戶B的優(yōu)先級高于用戶C，服務(wù)器現(xiàn)將INVITE轉(zhuǎn)發(fā)給用戶B，對應(yīng)圖上消息（2）；

被叫用戶B收到INVITE請求后，提示用戶并振鈴，并發(fā)送180（Ringing）消息通過服務(wù)器傳給主叫用戶，主叫用戶能聽到被叫用戶B的回鈴音，對應(yīng)圖上消息（3）（4）；

被叫用戶B忙，因此回送4XX消息，服務(wù)器接收后，由于是fo rk情況，因此不將此失敗響應(yīng)發(fā)送給主叫用戶，直接給被叫用戶回送ACK確認(rèn)，并將此初始請求消息INVITE繼續(xù)發(fā)送到第二個用戶C，對應(yīng)圖上消息（5）（6）（7）；

被叫用戶C收到INVITE請求后，提示用戶并振鈴，并發(fā)送180（Ringing）消息通過服務(wù)器傳給主叫用戶，并進(jìn)一步的發(fā)送200 0K響應(yīng)接續(xù)通話，對應(yīng)圖上消息（8）（9）（10）（11）；

主叫收到成功響應(yīng)后，回送ACK消息到被叫用戶B予以證實，呼叫建立，對應(yīng)圖上的（12）和（13）；

篇7

一、IMS－NGN網(wǎng)絡(luò)概況

IMS(IP Multimedia Subsystem)是IP多媒體系統(tǒng), 是新一代的通信理念，它能夠滿足現(xiàn)在的終端客戶更新穎、更多樣化多媒體業(yè)務(wù)的需求，也是解決移動與固網(wǎng)融合，引入語音、數(shù)據(jù)、視頻三重融合等差異化業(yè)務(wù)的重要方式。IMS把原有的垂直型的網(wǎng)絡(luò)架構(gòu)演進(jìn)成了水平的網(wǎng)絡(luò)架構(gòu)，并且獨立出了業(yè)務(wù)應(yīng)用層，從而使得不同的業(yè)務(wù)應(yīng)用之間的互操作性和共享性更為靈活。SIP（Session Initiation Protoca1）稱為會話初始協(xié)議，是用于在IP網(wǎng)絡(luò)中建立、修改和終止多媒體會話的一種應(yīng)用層控制協(xié)議。SIP是由IETF組織于1999年提出的一個在基于IP網(wǎng)絡(luò)中，特別是在Internet結(jié)構(gòu)的網(wǎng)絡(luò)環(huán)境中，實現(xiàn)實時通信應(yīng)用的一種信令協(xié)議。

3GPP組織在Release 5及Release 6階段對IP多媒體應(yīng)用領(lǐng)域進(jìn)行了詳細(xì)的分析研究，Release 5完成了IP多媒體子系統(tǒng)（IMS）核心網(wǎng)的組網(wǎng)框架、公共組件及基本業(yè)務(wù)流程定義，Release 6在對Release 5相關(guān)部分進(jìn)一步擴展更新基礎(chǔ)上，增加了對IMS關(guān)鍵業(yè)務(wù)能力、QoS保障、網(wǎng)絡(luò)互通以及IMS/CS融合等方面的定義。這個由3GPP組織提出的IMS架構(gòu)和思路被業(yè)界公認(rèn)為是比較完善的針對IP多媒體領(lǐng)域的解決方案，面向CDMA2000接入的3GPP2標(biāo)準(zhǔn)組、面向固網(wǎng)的TISPAN（Telecommunications and Internet converged Services and Protocols for Advanced Networking）標(biāo)準(zhǔn)組均以3GPP IMS模型作為基礎(chǔ)和參照進(jìn)行了相應(yīng)IP多媒體網(wǎng)絡(luò)架構(gòu)和業(yè)務(wù)體系的定義。

圖1、IMS網(wǎng)絡(luò)的演進(jìn)

NGN通過控制承載分離，構(gòu)成一個分布的系統(tǒng)結(jié)構(gòu)。使整體建網(wǎng)成本大大降低，網(wǎng)絡(luò)升級容易，便于加快新業(yè)務(wù)和新應(yīng)用的開發(fā)和部署，快速實現(xiàn)低成本全網(wǎng)統(tǒng)一業(yè)務(wù)覆蓋。簡化了網(wǎng)絡(luò)層次結(jié)構(gòu)提高了網(wǎng)絡(luò)資源利用率，減少了傳統(tǒng)電路交換機中繼互聯(lián)的復(fù)雜性和降低了承載網(wǎng)的成本。

二、IMS的網(wǎng)絡(luò)架構(gòu)：

圖2、3GPP IMS網(wǎng)絡(luò)架構(gòu)示意圖

IMS網(wǎng)絡(luò)架構(gòu)，利用SIP的靈活性，可支持無線網(wǎng)絡(luò)中大量的電話和非電話業(yè)務(wù)。該體系按其邏輯功能可分成3層：即傳送網(wǎng)絡(luò)層（包括終端網(wǎng)關(guān)等）、會話控制層和應(yīng)用服務(wù)層，因而體系結(jié)構(gòu)采用控制和承載相分離的方式如圖3所示，分為接入互聯(lián)層、會話控制層、和應(yīng)用層。

圖3、IMS網(wǎng)絡(luò)功能實體

接入互聯(lián)層完成的主要功能包括各類SIP終端SIP會話的發(fā)起終結(jié)；實現(xiàn)IP分組承載各種承載類型之間的轉(zhuǎn)換；根據(jù)業(yè)務(wù)部署和會話層的控制實現(xiàn)各種QoS策略；完成與傳統(tǒng)PSTN/PLMN間的互聯(lián)互通等功能。

會話層完成基本會話的控制，完成用戶注冊、SIP會話路由控制、和應(yīng)用服務(wù)器交互執(zhí)行應(yīng)用業(yè)務(wù)中的會話、維護管理用戶數(shù)據(jù)、管理業(yè)務(wù)QoS策略等功能，和應(yīng)用層一起為所有用戶一致的業(yè)務(wù)環(huán)境。會話層包括CSCF(Call Server Control Function)、MRFC(Multimedia Resource Function Controller)、BGCF(Breakout Gateway Control Function)、IM-SSF(IP Multimedia Service Switching Function)等功能實體。其中CSCF包括P-CSCF（Proxy CSCF）、I-CSCF（Interrogating CSCF）、S-CSCF（Serving CSCF）等類型，在物理上可以是合一的，也可以分別設(shè)置。P-CSCF是UE接入IMS系統(tǒng)的入口，實現(xiàn)了在SIP協(xié)議中的Proxy和User Agent功能。S-CSCF在IMS核心網(wǎng)中處于核心的控制地位，負(fù)責(zé)對UE的注冊鑒權(quán)和會話控制，執(zhí)行針對主叫端及被叫端IMS用戶的基本會話路由功能，并根據(jù)用戶簽約的IMS觸發(fā)規(guī)則，在條件滿足時進(jìn)行到AS（Application Server）的增值業(yè)務(wù)觸發(fā)及業(yè)務(wù)控制交互。I-CSCF在IMS核心網(wǎng)中起到關(guān)口節(jié)點的作用，提供本域用戶服務(wù)節(jié)點分配、路由查詢以及不同IMS域間拓?fù)潆[藏等功能。

應(yīng)用層，向用戶提供業(yè)務(wù)邏輯，包括實現(xiàn)傳統(tǒng)的基本電話業(yè)務(wù)，如呼叫前轉(zhuǎn)、呼叫等待、會議等業(yè)務(wù)；實現(xiàn)CS和PS已有的智能業(yè)務(wù)、基于SIP的非傳統(tǒng)電信業(yè)務(wù)等豐富的娛樂、游戲業(yè)務(wù)。

三、IMS的業(yè)務(wù)流程：

IMS控制層通過SIP(RFC 3261)基本協(xié)議建立、改變或結(jié)束多媒體會話及媒體協(xié)商。SIP協(xié)議具備以下優(yōu)點：

（1）與媒體無關(guān)的會話控制可以使SIP支持豐富的多媒體通信。

（2）SIP地址與終端位置的無關(guān)性使SIP用戶天生具有移動性。

（3）協(xié)議簡單，易于擴展，使SIP協(xié)議能夠支持許多新業(yè)務(wù)；對不支持業(yè)務(wù)信令的透明封裝，可以繼承多種已有的業(yè)務(wù)。

（4）使用SIP智能終端可以將網(wǎng)絡(luò)設(shè)備的復(fù)雜性推向邊緣，簡化網(wǎng)絡(luò)核心部分。

下面介紹SIP協(xié)議在IMS業(yè)務(wù)流程控制中的應(yīng)用。

圖4、IMS呼叫流程簡化結(jié)構(gòu)

如圖所示，當(dāng)A用戶想要與B用戶進(jìn)行會話時，UE A就生成一個SIP INVITE請求，并且通過GM參考點將該請求發(fā)送給P-CSCF。P-CSCF會對用戶A進(jìn)行鑒權(quán)，若A為合法用戶且簽訂了相應(yīng)租約，P-CSCF通過Mw參考點轉(zhuǎn)發(fā)給S-CSCF。S-CSCF繼續(xù)處理這個請求，執(zhí)行服務(wù)控制，包括與應(yīng)用服務(wù)器（AS）的交互，并且通過SIP INVITE請求中的用戶B的身份最終確定用戶B的歸屬運營商的入口點。I-CSCF會通過Mw參考點收到該請求，并且通過Cx參考點來聯(lián)系HSS，以找到正在為用戶B提供服務(wù)的S-CSCF。該S-CSCF負(fù)責(zé)處理這個終結(jié)的會話，包括與服務(wù)器AS的交互，并最終通過Mw參考點將這個請求發(fā)送給P-CSCF。經(jīng)過進(jìn)一步處理后（例如壓縮和隱私檢查），P-CSCF通過Gm參考點將這個SIP INVITE請求發(fā)送給UE B。 UE B生成一個183響應(yīng)，該響應(yīng)經(jīng)過與INVITE消息相同路徑反向傳回給UE A。再經(jīng)過幾次往返協(xié)商后，UE A和UE B完成會話建立。

會話結(jié)束時，UE A（或UE B）發(fā)起SIP BYE請求，該請求沿著INVITE相同路徑傳送給UE B（或UE A），UE B返回一個200（OK）響應(yīng)，沿途的CSCF和所有的AS都會清除與本次會話有關(guān)的所有對話狀態(tài)信息，SIP就完成了一次IMS業(yè)務(wù)流程控制。

四、結(jié)束語：

SIP及基于SIP的IMS業(yè)務(wù)體系為NGN的開發(fā)打下了基礎(chǔ)，顯示出巨大的潛力，全球已有50%的運營商部署了IMS?；贗MS架構(gòu)的移動固定融合網(wǎng)絡(luò)是能夠得到普遍認(rèn)同的最佳解決方案。

參考文獻(xiàn)：

[1]《3G IP多媒體子系統(tǒng)IMS--融合移動網(wǎng)與因特網(wǎng)》 （芬）Gonzalo Camarillo,Miguel A.García-Martin張同須譯 人民郵電出版社 2009

[2]《IMS技術(shù)原理及應(yīng)用》 胡樂明 曹磊 陳潔 電子工業(yè)出版社 2008

篇8

通過采用AJAX及SIP通訊協(xié)議，設(shè)計一個WebService并以Web為接口的端對端異步通信實例，闡釋W(xué)ebService雙向通訊的建構(gòu)方式，同時對AJAX技術(shù)、SIP通訊協(xié)議的原理與應(yīng)用作簡要介紹。

1.1WebService雙向通信機制

如圖1所示[1]，建立Client/Server雙向通信的松散連接及緊密連接架構(gòu)，WebService雙向通信包含了一個Client的主動請求和一個Server端的前項式Push或事件通知。這是從服務(wù)互動的觀點來設(shè)計的，最少會包含這3種型態(tài)，而每一個端點都像這樣具備Client與Server的功能設(shè)計。

（1）TYPEI是一個常見的單向WebService交互式樣板；Rc：表示Client端初始化一個請求，這個請求可以接收響應(yīng)或是不需要響應(yīng)。

（2）TYPEII是一個ServertoClient的異步Reply與EventNotification的交互式樣板，實際上異步Reply常被塑造成EventNotification的模式，有ACK就響應(yīng)，否則就是Notification；Es：表示Server的事件通知，可以要求具有ACK的響應(yīng)，也可以是一個事件通知。

（3）TYPEIII與TYPEI相反；Rs：表示Server端初始化一個請求，這個請求可以接收響應(yīng)或是不需要響應(yīng)。

圖1中實心的箭頭是初始化請求，虛線則是選擇性的信息響應(yīng)，TYPEIServer必須提供適當(dāng)?shù)腤SDL，通過SOAP傳遞給Client來使用，TYPEII和TYPEIII在Client必須提供適當(dāng)?shù)腤SDL，通過SOAP傳遞給Server來使用，而WebService人需同時具備TYPEI～TYPEIII的行為能力，在一個WebService的端點中同時存在Client/Server的角色時就會出現(xiàn)狀態(tài)協(xié)調(diào)性的問題，如果協(xié)調(diào)性出現(xiàn)問題就會出現(xiàn)錯誤，傳統(tǒng)WSDL是One-way方式，要實現(xiàn)WebService雙向通信就要做動態(tài)的設(shè)計。

1.2AJAX技術(shù)

AJAX的全名為AsynchronousJavaScriptandXML，是JavaScript及XML等技術(shù)的結(jié)合體，另外AJAX也包含瀏覽器端如何呼叫服務(wù)器端WebService的HTTPRequest技術(shù)[3]。從AJAX全名的字義中可以了解，AJAX就是異步的JavaScript與XML，它突破了傳統(tǒng)網(wǎng)頁開發(fā)技術(shù)的限制，使得網(wǎng)頁更具互動性。

1.3SIP通訊協(xié)議的原理與應(yīng)用

SIP是一個應(yīng)用層的控制通訊協(xié)議，可以建立、修改或結(jié)束多媒體聯(lián)機[4]。以O(shè)SI定義的網(wǎng)絡(luò)七層來分類，SIP應(yīng)該屬于會話層，但是也有人將其歸類在廣義的應(yīng)用層。

SIP目前共定義九大邏輯組件[5]，因該文僅使用到ProxyServer這個組件，利用該組件的原理，將該組件的部分功能設(shè)計成WebService。ProxyServer是一個中介組件，同時具有Server與Client的雙重角色，相當(dāng)于H.323中的Gatekeeper，通常SIPUserAgent發(fā)出請求時并不知道對方的地址，需要ProxyServer從中協(xié)助，當(dāng)ProxyServer無法取得SIPUserAgent所要求的聯(lián)機對象的地址時，ProxyServer會通過預(yù)設(shè)的路由選擇方式轉(zhuǎn)送給其他ProxyServer代為解析，此時轉(zhuǎn)送請求的ProxyServer便會成為Client端。如圖2所示，以INVITE為例，假設(shè)Smith要用SIPPhone與John通話，首先Smith與John的SIPPhone要先分別向各自的SIPProxy注冊，接著Smtih的SIPPhone發(fā)出INVITERequest，其中INVITERequest中會有幾個標(biāo)頭字段：Via、To、From、Call-ID、CSeq、Contact、Max-Forward、Content-Type、Content-Length。因為Smith的SIPPhone并不知道John的地址或是John所注冊的SIPProxy地址，Smith會將INVITERequest送到自己所注冊的SIPProxy（Smith’sProxy），Smith’sProxy會回傳100（Trying）給Smith的SIPPhone，100（Trying）表示Proxy已經(jīng)收到并處理INVITERequest，而Smith’sProxy會根據(jù)IP或是域名找到John的SIPPhone所注冊的Proxy，在把INVITERequest傳送出去之前，Smith’sProxy會先將自己的地址填在Via字段，加到INVITERequest的標(biāo)頭，然后送到John的SIPPhone所注冊的Proxy（John’sProxy），而John’sProxy則會在收到INVITE訊息后回傳100（Trying）給Smith’sProxy，表示已經(jīng)收到并處理INVITERequest，此時John’sProxy會查詢數(shù)據(jù)庫，找到John目前所在的IP地址，之后John’sProxy會將自己的地址填在Via字段，加到INVITERequest的標(biāo)頭并將INVITERequest傳送給John的SIPphone。在收到INVITE信息后，John的SIPPhone會進(jìn)入Ringing的狀態(tài)，并依照先前所紀(jì)錄的Via字段，依照路徑回傳180（Ringing）訊息給Smith的SIPPhone并告知John有來電。當(dāng)Smith的SIPPhone收到180（Ringing）信息后，可以顯示某些信息并等待John接起電話，若John接起電話，表示John允許建立聯(lián)機，John的SIPPhone響應(yīng)200（OK）信息給Smith的SIPPhone，而200（OK）的訊息中，可以攜帶John希望建立RTP封包聯(lián)機的相關(guān)信息和參數(shù)（IP地址與Port）的SDP給Smith，其中SDP是附加在SIPMessage后面。此時Smith的SIPPhone因應(yīng)200（OK）的信息響應(yīng)ACK給John的SIPPhone，兩端SIP聯(lián)機就算是建立完成，此時便可以利用之前Message所攜帶的SDP里的相關(guān)參數(shù)，開始傳輸RTP封包。若John拒絕受話，則John的SIPPhone就會傳送一個CANCEL訊息給Smith的SIPPhone。

2結(jié)語

過去在瀏覽器上運行需要單向、雙向，全雙工、半雙工的服務(wù)（如聊天室、語音通話、視訊等）都存在一些問題，網(wǎng)頁聊天室采用共通的Session或全局變量來達(dá)成信號溝通的目的，而瀏覽器也會定時PostBack，造成Client端瀏覽器換頁的動作產(chǎn)生，也會存在一些Session中斷或是無法清除的問題，對于實時的訊號交換是一個瓶頸，許多運行順暢的語音或視訊軟件，都是以ActiveX或是Applet的組件嵌入方式安裝在Client端瀏覽器中，運用了AJAX的方式呼叫CallBack機制后，尋找可用的WebService，結(jié)合SIP通信協(xié)議，讓信息或軟件可以快速地組合出新的服務(wù)，也可以達(dá)到信號實時交換的需求，另外提供了一種快速開發(fā)以瀏覽器為用戶端軟件系統(tǒng)的新方式，而Client瀏覽器不再需要一直進(jìn)行更新網(wǎng)頁的動作，也不需要嵌入任何組件，這對目前很多使用者因嵌入不明組件造成中毒或是黑客入侵，有實質(zhì)上的幫助，提高信息安全的防護。

參考文獻(xiàn)

[1] ZhenshengWu.AWayofUsingWebServicebyAJAX[C]//Proceedingsof2008InternationalSymposiumonDistributedComputingandApplicationsforBusinessEngineeringandScience.2005.

[2] WuChou，F(xiàn)engLiu.WebServiceforTele-Communication[C]//ProceedingsoftheAdvancedInternationalConferenceonTelecommunicationsandInternationalConferenceonInternetandWebApplicationsandServices.2006.

[3] 謝延紅，錢愛增.利用Ajax技術(shù)開發(fā)無刷新聊天室系統(tǒng)[J].長春師范學(xué)院學(xué)報，2007，26（6）：86-89.

[4] 施昌偉.基于SIP協(xié)議的即時通訊系統(tǒng)的研究與實現(xiàn)[D].南京郵電大學(xué)，2012.

篇9

1 引言

基于SIP協(xié)議的即時通信系統(tǒng)在企事業(yè)單位使用較多，而隨著單位保密意識的提高，對數(shù)據(jù)安全和網(wǎng)絡(luò)安全的重視，人們對防火墻訪問規(guī)則等安全策略的要求越來越嚴(yán)格，同時也限制了其基于計算機的各種應(yīng)用，阻礙了其業(yè)務(wù)的發(fā)展。本文采用HTTP Tunnel實現(xiàn)對防火墻的穿越，將TCP、UDP等非HTTP數(shù)據(jù)類型進(jìn)行HTTP偽裝和加密，在不改變單位的防火墻等安全策略的前提下，以隱蔽通信的方式完成應(yīng)用程序的數(shù)據(jù)傳輸。

本文重點探討了HTTP Tunnel技術(shù)在以SIP協(xié)議為基礎(chǔ)的即時通信系統(tǒng)中的應(yīng)用，并提出相應(yīng)解決方案和參考應(yīng)用框架。旨在提升HTTP Tunnel技術(shù)的應(yīng)用范圍，加強應(yīng)用業(yè)務(wù)的數(shù)據(jù)安全與網(wǎng)絡(luò)安全。

2 應(yīng)用系統(tǒng)框架

HTTP Tunnel被稱之為HTTP暗道，原理是將數(shù)據(jù)偽裝成 HTTP的數(shù)據(jù)形式來穿過防火墻。

基于SIP協(xié)議的即時通信系統(tǒng)是以SIP為信令交互協(xié)議的即時通信系統(tǒng)，其應(yīng)用包括HTTP訪問、即時消息、語音通信、視頻通信等。該系統(tǒng)通過HTTP Tunnel可以不用改變防火前的安全策略，即可實現(xiàn)自由通信。其框架基本包括四個主要方面：

1） 基于SIP協(xié)議的即時通信系統(tǒng)，該系統(tǒng)實現(xiàn)基于TCP、UDP、HTTP等協(xié)議的即時通信功能；

2） Sock2HTTP服務(wù)器，該服務(wù)器實現(xiàn)非HTTP協(xié)議數(shù)據(jù)包的HTTP格式轉(zhuǎn)換，通信端口映射，擁塞控制等功能；

3） HTTP Tunnel系統(tǒng)，該系統(tǒng)實現(xiàn)基于HTTP協(xié)議的雙向的虛擬數(shù)據(jù)連接，從而穿越防火墻；

4） HTTP2Sock服務(wù)器，該服務(wù)器實現(xiàn)需要轉(zhuǎn)換為其他格式的HTTP數(shù)據(jù)，通信端口的映射，擁塞控制等。

其拓?fù)鋱D如圖1：

圖1.基于SIP協(xié)議的即時通信系統(tǒng)的HTTP Tunnel應(yīng)用

3應(yīng)用系統(tǒng)設(shè)計

3.1基于SIP協(xié)議的即時通信系統(tǒng)

基于SIP協(xié)議的即時通信系統(tǒng)主要有兩部分組成。OpenSIPS服務(wù)器和oSIP客戶端。

3.1.1 OpenSIPS

OpenSIPS是成熟的開源SIP服務(wù)器，結(jié)構(gòu)非常靈活，其核心路由功能完全通過腳本來實現(xiàn)，可靈活定制各種路由策略，可靈活應(yīng)用于語音、視頻通信、IM以及Presence等多種應(yīng)用。

其主要功能如下：

 SIP注冊服務(wù)器/服務(wù)器/重定向服務(wù)器

 SIP presence agent

 SIP IM Server

3.1.2 oSIP

oSIP是使用標(biāo)準(zhǔn)c編寫的SIP協(xié)議棧。

主要包括兩部分的內(nèi)容：狀態(tài)機模塊、解析器模塊。

 狀態(tài)機模塊的功能：完成對某個事務(wù)（注冊過程，呼叫過程等等）狀態(tài)記錄，并在特定狀態(tài)下觸發(fā)相應(yīng)的事件或回調(diào)函數(shù)。

 解析器模塊的功能：該模塊主要完成對SIP消息結(jié)構(gòu)剖析、SDP消息的結(jié)構(gòu)剖析以及URI結(jié)構(gòu)的剖析；

圖2.oSIP結(jié)構(gòu)

oSIP為SIP協(xié)議的客戶端，OpenSIPS為SIP協(xié)議的服務(wù)器，二者共同搭建基于SIP協(xié)議的即時通信系統(tǒng)。

3.2 Sock2HTTP服務(wù)器和HTTP2Sock服務(wù)器

當(dāng)位于內(nèi)網(wǎng)的SIP終端訪問外網(wǎng)，則終端建立連接的端口不一定被防火墻開放，尤其是UDP端口，若使TCP與UDP等消息穿越防火墻則需要相應(yīng)的協(xié)議轉(zhuǎn)換服務(wù)器，即Sock2HTTP和HTTP2Sock。

圖3.Sock2HTTP與HTTP2Sock

3.2.1功能描述

主要負(fù)責(zé)分配對應(yīng)的UDP端口；接收HTTP消息、解碼、以UDP的形式發(fā)送至目的地址；接收UDP消息、編碼、接收終端分配UDP端口的HTTP消息，返回生成的UDP端口；UDP端口與終端的對應(yīng)管理機制。

3.2.2設(shè)計說明

a．建立TCP套接字，與某端口綁定（可配置），監(jiān)聽該端口；

b．接收到請求后，fork子進(jìn)程處理該請求,請求包括要求分配端口的請求和其他請求兩類；

c．處理要求分配端口的請求，將分配的端口返回給終端，保持該TCP鏈接不斷開，直至通話結(jié)束或者終端注銷。

4結(jié)論

基于SIP協(xié)議的即時通信系統(tǒng)使用HTTP Tunnel技術(shù)，在企事業(yè)單位網(wǎng)內(nèi)外實現(xiàn)自由通信。該應(yīng)用不僅提升HTTP Tunnel技術(shù)的應(yīng)用范圍，更加強應(yīng)用業(yè)務(wù)的數(shù)據(jù)安全與網(wǎng)絡(luò)安全。系統(tǒng)采用分布式設(shè)計，為系統(tǒng)升級和集成提供很好的構(gòu)架基礎(chǔ)，是企事業(yè)單位業(yè)務(wù)和數(shù)據(jù)穿越防火墻的一種安全和高效的應(yīng)用。

參考文獻(xiàn)

[1] RFC 2543 3261SIP: Session Initiation Protocol.

篇10

1、在高跟鞋中1厘米等于25px , 所以175px就是7厘米。所以高跟鞋175px是指跟高跟鞋跟高有7厘米。

2、高跟鞋的“健康極限”在7厘米，如果超過了7厘米就會導(dǎo)致身體前傾，腳部的負(fù)擔(dān)也會增加，會引發(fā)很多骨科疾病。所以，鞋跟的高度最好在7厘米以下。

（來源：文章屋網(wǎng) ）