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

篇1

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

1 引言

第三代合作伙伴3GPP選擇sip協(xié)議作為第三代移動(dòng)通信系統(tǒng)的IP多媒體子系統(tǒng)（IMS）心靈協(xié)議，是因其具有靈活、無(wú)縫和可擴(kuò)展性，它將逐漸成為下一代網(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)一步的完善與擴(kuò)充，但是如果協(xié)議在設(shè)計(jì)環(huán)節(jié)出現(xiàn)任何問題都會(huì)給系統(tǒng)帶來(lái)難以預(yù)料的影響，所以為保證協(xié)議的穩(wěn)定性和安全性，應(yīng)在早期開發(fā)時(shí)盡可能挖掘其隱蔽的問題并找出解決方案。

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

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

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

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

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

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

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

3.1 總體流程建模

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

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

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

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

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

3.3 具體行為建模

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

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

當(dāng)收到UAS會(huì)送的響應(yīng)消息時(shí)，變遷CallResp被點(diǎn)火執(zhí)行，即運(yùn)行其對(duì)應(yīng)的函數(shù)代碼。此函數(shù)代碼中sta與st均為SCENEC型變量，st是處理消息前UAC的狀態(tài)，sta為處理消息后UAC的狀態(tài)。Action部分調(diào)用函數(shù)call_resp（st，resp）完成UAC對(duì)不同類型響應(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分層模型，對(duì)該協(xié)議總體流程、網(wǎng)絡(luò)層、UAS與UAC間的具體行為在不同模型層次上分別進(jìn)行建模。該層次模型規(guī)?？煽?、功能劃分直觀、數(shù)據(jù)結(jié)構(gòu)完備，為建模后期協(xié)議的驗(yàn)證與改進(jìn)提供了較完善的模型基礎(chǔ)。

參考文獻(xiàn)：

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

篇2

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

1 引言

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

2 SIP協(xié)議

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

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

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

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

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

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

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

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

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

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

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

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

考慮SIP在企業(yè)網(wǎng)中的實(shí)際應(yīng)用，本文按照SIP協(xié)議規(guī)范提出了一套VOIP電話系統(tǒng)設(shè)計(jì)方案，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)基本工作流程

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

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

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

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

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

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

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

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

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

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

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

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

篇3

中圖分類號(hào)：TN915.04 文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：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）是一個(gè)會(huì)話層的信令控制協(xié)議，它獨(dú)立于底層協(xié)議，用于建立、修改和終止IP網(wǎng)上的雙方或多方的多媒體會(huì)話。1999年由IETF組織提出，它是一個(gè)在基于IP網(wǎng)絡(luò)中，實(shí)現(xiàn)實(shí)時(shí)通信應(yīng)用的一種協(xié)議。SIP支持、重定向、登記定位用戶等功能，支持用戶移動(dòng)，與RTP/RTCP、SDP、RTSP、DNS等協(xié)議配合，可支持和應(yīng)用于語(yǔ)音、視頻、數(shù)據(jù)等多媒體業(yè)務(wù)，同時(shí)可以應(yīng)用于presence（呈現(xiàn)）、instant message（即時(shí)消息）等特色業(yè)務(wù)。它的應(yīng)用非常靈活。

SIP有下面五個(gè)基本功能：

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

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

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

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

（五）管理會(huì)話：可以更改會(huì)話參數(shù)或中止會(huì)話。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)中支持多媒體會(huì)話及其他基于SIP協(xié)議的業(yè)務(wù)，目的將蜂窩移動(dòng)通信和互聯(lián)網(wǎng)技術(shù)結(jié)合起來(lái)，能提供綜合業(yè)務(wù)的下一代通信網(wǎng)絡(luò)，它獨(dú)立于接入和承載技術(shù)，即IMS的核心特點(diǎn)是采用SIP協(xié)議和與接入的無(wú)關(guān)性。

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

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

SIP信令消息從移動(dòng)用戶發(fā)起，經(jīng)UMTS（通用移動(dòng)通信系統(tǒng)）陸地?zé)o線接入網(wǎng)絡(luò)進(jìn)入核心網(wǎng)，通過SGSN（GPRS服務(wù)支持節(jié)點(diǎn)）和GGSN（GPRS網(wǎng)關(guān)支持節(jié)點(diǎn)）到達(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時(shí)，由于SIP的靈活性和可擴(kuò)展性，決定采用SIP機(jī)制作為IMS網(wǎng)絡(luò)的會(huì)話初始化協(xié)議。3G網(wǎng)絡(luò)被分為3個(gè)不同的域：電路交換域、分組交換域和IP多媒體交換域。其中IP多媒體子系統(tǒng)域是3G中最重要的域，這個(gè)域采用SIP作為主要的信令協(xié)議向用戶提供基于因特網(wǎng)的多媒體服務(wù)。從邏輯上講，所有的3G終端都包含一個(gè)SIP用戶，IP多媒體網(wǎng)絡(luò)節(jié)點(diǎn)就是SIP規(guī)范中所提到的。

篇4

一、前言

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

二、問題提出

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

三、擴(kuò)展協(xié)議設(shè)計(jì)

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

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

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

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

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

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

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

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

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

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

篇5

引言

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

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

1.1軟交換的概念

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

1.2 SIP協(xié)議介紹

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

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

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

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

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

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

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

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

本系統(tǒng)以面向?qū)ο蟮姆椒ㄔO(shè)計(jì)了一個(gè)滿足系統(tǒng)要求的最小SIP和SDP協(xié)議棧。SIP協(xié)議棧支持INVITE，ACK，BYE，REGISTER和CANCEL請(qǐng)求，支持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中的頭部字段都是以類的形式實(shí)現(xiàn)的，所支持的頭部字段都是從一個(gè)抽象類Header繼承而來(lái)。抽象類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，主要用來(lái)對(duì)相應(yīng)的頭部字段進(jìn)行解析，getName方法返回當(dāng)前的頭部字段類的類名，encode方法用來(lái)產(chǎn)生相應(yīng)的頭部字段的字符串。

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

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

3 結(jié)束語(yǔ)

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

參考文獻(xiàn)

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

篇6

中圖分類號(hào)：TP393.0

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

DOI： 10.3969/j.issn.1003-6970.2015.07.025

0 SIP簡(jiǎn)介

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

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

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

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

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

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

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

1 forking功能

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

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

1.1 終端處理原則

（1）請(qǐng)求

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

（2）響應(yīng)

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

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

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

1.2 處理原則

（1）請(qǐng)求

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

（2）響應(yīng)

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

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

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

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

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

當(dāng)被叫終端注冊(cè)了多個(gè)Contact地址時(shí)，SIP協(xié)議需要去提取碼流中的相關(guān)字段，通過Accept-Contact，Reject-Contact參數(shù)確定好被叫目標(biāo)集，并按照優(yōu)先級(jí)將多個(gè)被叫終端進(jìn)行排序，進(jìn)一步的提取Request-Disposition頭部的關(guān)鍵信息，對(duì)是否需要進(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是用來(lái)指示是否需要fork，當(dāng)指示為”no-fork”時(shí)，雖然被叫有多個(gè)，但是初始請(qǐng)求只會(huì)發(fā)送給優(yōu)先級(jí)最高的被叫終端并不會(huì)產(chǎn)生分叉，如果指示為”fork”時(shí)，則進(jìn)一步的讀取parallel-directive指示的值，parallel-directive若為“parallel”為并行fork，并行fork則需要被叫歸屬的服務(wù)器將初始的INVITE請(qǐng)求同時(shí)發(fā)送給多個(gè)被叫終端，既并行呼叫；若為“sequential”為串行fork，串行fork則不需要服務(wù)器將初始請(qǐng)求同時(shí)發(fā)送給多個(gè)被叫終端，而是逐個(gè)的發(fā)送，先發(fā)給第一個(gè)優(yōu)先級(jí)最高的被叫，如果接通，則不需要進(jìn)行后續(xù)處理，如果沒有成功接續(xù)，則繼續(xù)發(fā)送給第二個(gè)被叫，依次類推。

2.2 TU中會(huì)話的維護(hù)

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

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

3 具體流程

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

3.1 并行流程

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

各步驟的具體含義如下：

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

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

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

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

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

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

3.2 串行流程

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

各步驟的具體含義如下：

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

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

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

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

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

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

篇7

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

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

3GPP組織在Release 5及Release 6階段對(duì)IP多媒體應(yīng)用領(lǐng)域進(jìn)行了詳細(xì)的分析研究，Release 5完成了IP多媒體子系統(tǒng)（IMS）核心網(wǎng)的組網(wǎng)框架、公共組件及基本業(yè)務(wù)流程定義，Release 6在對(duì)Release 5相關(guān)部分進(jìn)一步擴(kuò)展更新基礎(chǔ)上，增加了對(duì)IMS關(guān)鍵業(yè)務(wù)能力、QoS保障、網(wǎng)絡(luò)互通以及IMS/CS融合等方面的定義。這個(gè)由3GPP組織提出的IMS架構(gòu)和思路被業(yè)界公認(rèn)為是比較完善的針對(duì)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)成一個(gè)分布的系統(tǒng)結(jié)構(gòu)。使整體建網(wǎng)成本大大降低，網(wǎng)絡(luò)升級(jí)容易，便于加快新業(yè)務(wù)和新應(yīng)用的開發(fā)和部署，快速實(shí)現(xiàn)低成本全網(wǎng)統(tǒng)一業(yè)務(wù)覆蓋。簡(jiǎn)化了網(wǎng)絡(luò)層次結(jié)構(gòu)提高了網(wǎng)絡(luò)資源利用率，減少了傳統(tǒng)電路交換機(jī)中繼互聯(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ú)線網(wǎng)絡(luò)中大量的電話和非電話業(yè)務(wù)。該體系按其邏輯功能可分成3層：即傳送網(wǎng)絡(luò)層（包括終端網(wǎng)關(guān)等）、會(huì)話控制層和應(yīng)用服務(wù)層，因而體系結(jié)構(gòu)采用控制和承載相分離的方式如圖3所示，分為接入互聯(lián)層、會(huì)話控制層、和應(yīng)用層。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四、結(jié)束語(yǔ)：

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

參考文獻(xiàn)：

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

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

篇8

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

1.1WebService雙向通信機(jī)制

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

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

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

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

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

1.2AJAX技術(shù)

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

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

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

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

2結(jié)語(yǔ)

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

參考文獻(xiàn)

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

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

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

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

篇9

1 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.1 OpenSIPS

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

其主要功能如下：

 SIP注冊(cè)服務(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)機(jī)模塊、解析器模塊。

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

 解析器模塊的功能：該模塊主要完成對(duì)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é)議的即時(shí)通信系統(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é)分配對(duì)應(yīng)的UDP端口；接收HTTP消息、解碼、以UDP的形式發(fā)送至目的地址；接收UDP消息、編碼、接收終端分配UDP端口的HTTP消息，返回生成的UDP端口；UDP端口與終端的對(duì)應(yīng)管理機(jī)制。

3.2.2設(shè)計(jì)說明

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

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

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

4結(jié)論

基于SIP協(xié)議的即時(shí)通信系統(tǒng)使用HTTP Tunnel技術(shù)，在企事業(yè)單位網(wǎng)內(nèi)外實(shí)現(xiàn)自由通信。該應(yīng)用不僅提升HTTP Tunnel技術(shù)的應(yīng)用范圍，更加強(qiáng)應(yīng)用業(yè)務(wù)的數(shù)據(jù)安全與網(wǎng)絡(luò)安全。系統(tǒng)采用分布式設(shè)計(jì)，為系統(tǒng)升級(jí)和集成提供很好的構(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厘米就會(huì)導(dǎo)致身體前傾，腳部的負(fù)擔(dān)也會(huì)增加，會(huì)引發(fā)很多骨科疾病。所以，鞋跟的高度最好在7厘米以下。

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