前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的sip協議主題范文，僅供參考，歡迎閱讀并收藏。

第1篇：sip協議范文

【關鍵詞】sip；H.323；XMPP；VOIP電話

【中圖分類號】TP3 11.1 【文獻標識碼】A 【文章編號】1672-5158（2013）01―0085―02

1 引言

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

2 SIP協議

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

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

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

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

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

3 SIP和H.323、XMPP協議的比較

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

H.323采用基于抽象語法標記ASN.1和壓縮編碼規則的簡潔的二進制編碼規則發送其各種形式的信息。XMPP是基于可擴展標記語言（XML）的協議，它繼承了在XML環境中靈活的擴展性，因此，基于XMPP的應用具有超強的可擴展性。而SIP以文本形式描述的協議，類似于HTTP。基于文本的編碼協議，能夠顯而易見的表示其頭域的意義，如From、To、Subject等域名。過去的實踐，已經充分證明了這種不需要復雜文檔說明的標準的優越性。

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

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

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

4 企業SIP電話設計方案

考慮SIP在企業網中的實際應用，本文按照SIP協議規范提出了一套VOIP電話系統設計方案，SIP終端不僅可以在企業內部網絡正常應用，也可以透過企業防火墻借助互聯網進行應用，圖2其系統結構示意圖。也就是說，企業IP電話網絡中使用私有地址的SIP終端可以作為被叫被外界SIP終端呼叫。這樣VOIP在企業網絡的應用才有意義。

4.1 系統基本工作流程

用戶注冊：用戶通過客戶機自動向SIP服務器端發送注冊信息；該服務器的SIP注冊服務模塊接收注冊信息后，要先對客戶端進行身份驗證，確認其合法后再對該用戶的狀態信息、IP地址信息等進行更新。

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

通話過程：如果A和B之問的通信鏈路建立成功，則他們之間直接進行通信直至會話結束，通話結束時向服務器發送會話結束請求。

4.2 系統協議結構

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

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

5 國內外SIP協議的應用

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

目前，采用H.323的VOIP服務對終端設備的要求較高。XMPP協議是IETF近期的標準，有待進一步完善。而SIP協議優勢非常明顯，它簡單靈活、分布控制，而且極易與其它服務集成。因此，在開發VOIP產品的同時，要關注SIP的發展，借鑒其有用之處。不可否認，在整個電信網絡中，一直存在采用H.323協議統一VOIP實現的呼聲，不過，電信廠商和運營公司均承認SIP的靈活性，并已采取行動利用SIP協議開發相關應用產品。

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

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

華為公司：近年來，華為公司認為隨著基于SIP的VoIP實現門檻越來越低，語音業務將逐步退出主導地位，成為一種最基本的業務。因此，華為公司不僅僅了基于SIP的語音網關產品，如：迅時MX51系列語音網關；還推出了基于SIP的融合通信產品eSpace。

據美國一家資訊公司對VOIP相關協議的實際應用情況和未來前景的預測，到2015年，SIP應用將達到全部VOIP相關安裝協議的46%，而H.323今后的應用比例將逐步下降。

第2篇：sip協議范文

關鍵詞:下一代網絡（NGN）；軟交換；SIP協議

引言

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

1系統開發的技術基礎

1.1軟交換的概念

我國信息產業部電信傳輸研究所對軟交換的定義是：“軟交換是網絡演進以及下一代分組網絡的核心設備之一，它獨立于傳送網絡，主要完成呼叫控制、資源分配、協議處理、路由、認證、計費等主要功能，同時可以向用戶提供現有電路交換機所能提供的所有業務，并向第三方提供可編程能力。”

1.2 SIP協議介紹

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

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

2 系統的總體設計和實現

2.1系統的層次結構

軟交換采用業務與交換分離的設計思想，在系統設計結構上將軟交換技術應用設計為三層結構，底層為用戶接入層，中間為交換支撐層，最上面是業務實現層。系統的層次結構如圖1所示。

2.2呼叫管理服務器的設計與實現

呼叫管理服務器處于該體系結構中的網絡控制層，它是軟交換系統的核心部分。呼叫管理服務器除了完成呼叫控制、連接控制和協議處理功能外，還將提供原來由網守設備提供的資源管理、路由以及認證、計費等功能。

軟交換系統的運行需要SIP協議棧和SDP協議棧。客戶端應該能夠產生INVITE和ACK請求，能夠產生和解析Call-ID，Content-Length，Content-Type，Cseq，From和To頭部字段。呼叫管理服務器應該能夠接收INVITE，ACK，BYE，CANCEL和REGISTER請求，應該能夠產生和解析Call-ID，Content-Length，Content-Type，Cseq，Expires，From，Max-Forwards，Via和To頭部字段。為了能夠使客戶端和服務端能夠使用RTP傳輸語音流，SDP協議應該能夠產生和解析v，o，s，c，t，m和a頭部字段。

本系統以面向對象的方法設計了一個滿足系統要求的最小SIP和SDP協議棧。SIP協議棧支持INVITE，ACK，BYE，REGISTER和CANCEL請求，支持100，180，200，300，400，500和600狀態應答，支持Subject，Contact，Call-ID，Content-Length，Content-Type，Cseq，Expires，From，Max-Forwards，Via和To頭部字段。SDP協議棧支持v，o，s，c，t，m和a頭部字段。SIP和SDP中的頭部字段都是以類的形式實現的，所支持的頭部字段都是從一個抽象類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，主要用來對相應的頭部字段進行解析，getName方法返回當前的頭部字段類的類名，encode方法用來產生相應的頭部字段的字符串。

其中SIP協議棧的結構如圖2所示：

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

3 結束語

總之，基于SIP協議軟交換系統的前景非常廣闊，在這個領域，有許多技術難題等待人們去解決。相信在大家的共同推動之下，軟交換系統的應用將得到快速的發展。

參考文獻

[1]強磊等編著.基于軟交換的下一代網絡組網技術[M].人民郵電出版社，2005

[2]秦維佳.C/C++程序設計教程[M].機械工業出版社，2007

第3篇：sip協議范文

1相關理論與技術

通過采用AJAX及SIP通訊協議，設計一個WebService并以Web為接口的端對端異步通信實例，闡釋WebService雙向通訊的建構方式，同時對AJAX技術、SIP通訊協議的原理與應用作簡要介紹。

1.1WebService雙向通信機制

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

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

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

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

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

1.2AJAX技術

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

1.3SIP通訊協議的原理與應用

SIP是一個應用層的控制通訊協議，可以建立、修改或結束多媒體聯機[4]。以OSI定義的網絡七層來分類，SIP應該屬于會話層，但是也有人將其歸類在廣義的應用層。

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

2結語

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

參考文獻

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

[2] WuChou，FengLiu.WebServiceforTele-Communication[C]//ProceedingsoftheAdvancedInternationalConferenceonTelecommunicationsandInternationalConferenceonInternetandWebApplicationsandServices.2006.

[3] 謝延紅，錢愛增.利用Ajax技術開發無刷新聊天室系統[J].長春師范學院學報，2007，26（6）：86-89.

[4] 施昌偉.基于SIP協議的即時通訊系統的研究與實現[D].南京郵電大學，2012.

[5] 張晨光.基于H.323協議的IP呼叫中心坐席終端設計與實現[D].北京郵電大學，2008.

第4篇：sip協議范文

1、（信末簽名后的）再者，又及；附言（略作P.S.，PS.，PS或p.s.）

2、（書等的）附錄；跋，補遺

3、[英]（新聞廣播后的）結束語

第5篇：sip協議范文

1.注重案例，制定課程標準。針對中職教育教學的特點，以崗位需求為導向，以學生圖形圖像處理以及平面設計的職業能力培養為目標，以工作過程的系統化和可持續發展為出發點，與企業行業合作共同進行基于工作過程的課程設計開發。根據對學生所從事工作崗位職業能力、工作任務、工作過程的分析，以圖形圖像處理和平面設計領域的典型案例構建教學內容；以真實設計項目和典型任務為載體，采用理實一體化教學模式，基于平面設計實際工作流程設計教學實施過程，創造最佳的基于工作過程的學習環境；以學生為中心，采用項目導向、任務驅動、案例教學等行動導向教學法實施教學，充分調動學生的學習積極性；合理利用網絡資源，多渠道拓展職業能力；充分體現課程職業性、實踐性和開放性的特點。

2.注重方法，培養操作技能。在整個教學進程中，以案例實訓貫穿于整個教學過程中，但各階段實訓內容、教學側重點不同。理論與實訓循環授課，“教、學、做”合一，針對每次課所講授的知識點，精選實訓內容，實訓目的在于鞏固所學知識點，并注意培養學生舉一反三的學習能力。實訓部分根據影視多媒體、廣告設計、動漫設計、藝術設計等工作崗位要求，安排綜合性案例，以模擬項目為主，通過臨摹優秀作品、模擬設計、自主設計等方式，注意啟發學生思維，啟發學生采取不同的方法完成，培養學生創新精神。使學生掌握本課程在職業崗位中的作用，掌握工作崗位知識、能力、素質要求，專業公司運作模式，實現課程與工作完全接軌，形成獨具特色的“教學做”一體化案例教學，培養實際工作技能。

3.注重能力，實施“教學做”一體化教學。注重能力培養，實施“教學做”一體化教學。經長期的教學做一體化的教學實踐，總結歸納出了Photoshop課程教學的課前準備、組織教學、示范演練、布置任務、巡回指導、小結等六步教學法，以能力培養為主，融合了教學做一體化的理念，更好地實現了教中學、學中做和做中學。

第6篇：sip協議范文

通常C波段電動極軸天線和傳統KU極軸天線組成使用 的條件是極軸天線、天線控制器、電動推桿。根據極軸天線面大小匹配對應功率的天線控制器和相應尺寸的電動推桿(常用12、18、24寸推桿,ku極軸天線使用推桿相對較小)。

就c波段極軸天饋系統而言,想要讓天線效率得到充分發揮,最好的辦法就是將正饋天線的ku高頻頭設為主焦,C波段高頻頭設為副焦;再通過DiSEqC 1.0切換器或者22k開關對2路衛星信號進行切換使用,這是極軸前輩曾文明老師提出的。而傳統支持DiSEqC1.0協議的天控器和衛星接收機只能單獨使用。即打算從1個衛星節目轉換到另1個衛星節目,需要先遙控天控器去驅動電動推桿,繼而在極軸天線定位后再把衛星接收機遙控切換到相應衛星的頻道上,需要操作2個遙控器才能去達成目的。

設備特點

TOPSIGNALTP8801型天控器除了可以推動普通KU天線外,還可以驅動3-5米直徑的極軸天線(需更換相應驅動單元);并能夠存儲多達99顆衛星位置。此外其最大的特點還有兼容普通衛星接收機使用的DiSEqC1.0協議,在沒有DiSEqC 1.2協議衛星接收機的情況下也可以單獨正常使用。而我所看中的正是其支持DiSEqC 1.2協議的功能。這樣就可以通過支持DiSEqC 1.2協議的衛星接收機(如DM500S、430)進行跨星換臺操作,該天控器會自動驅動極軸天線尋星定位后進行播放。這一先進的技術以前只在ku天線相關極軸產品上采用,如SVEC 9120、DG240等水平極軸座之類,而C波段極軸天線產品上鮮有使用。

從接口來看,TP8801與普通DiSEqC 1.0天控器略有不同。前者增加了1進1出的75-5的F信號端子,如果只使用DiSEqC 1.0協議功能時,只需把天控器的電源和推桿的4根相應控制線進行連接即可,即電源正負M1 M2 傳感器sensor GND。當使用DiSEqC1.2協議功能時,除了接好這4根控制線,還需要把衛星天線的F線接入天控器后,再輸出到帶有DiSEqC1.2協議的衛星接收機上。

調整天控器

由于筆者的3米SVEC C波段網狀極軸天線室外單元以前已經基本調試到位(只是KU波段主焦初調完成,C波段副焦信號尚可)。所以在使用TOPSIGNALTP8801天控器時只需在室內把原來的DiSEqC 1.0天線控制器線路進行連接更換即可。原極軸天線24寸推桿內已設置好東西邊界的硬件凸輪物理行程限位,此次無須再進行調整。否則需要對推桿設置清零,再對天控器進行極軸天線的軟件東西限位設定,或者在使用DM500S接收機時,通過極軸菜單設置對軟件東西邊界的設定進行操作。

首次使用該極軸天線控制器時,筆者建議各位最好用原來的天控器把極軸天線調動到正南方向再更換新天控器,此舉目的是配合新天控器天線進行零點設置。啟用新天線控制器時,開機會顯示000的狀態,這時再向左或者向右調節TP8801時,機身上的綠色數碼指示燈就會有脈沖計數指示。筆者的極軸天線正常使用時以正南為0點,極軸天線面左右接近1個平面。向左偏向時天線推桿向內拉動,極軸天線偏向東方,天控器的脈沖數字從0開始依次向上疊加。當極軸天線向右偏向時天線推桿向外推出,極軸天線偏向西方,天控器脈沖數字從999開始依次向下跌減。所以說,把極軸天線調整到正南方位再接入TP8801天控器是很有必要的,這樣可以直觀從天控器數據的變化中顯示出極軸天線究竟是偏向東邊或者西邊。

對于使用普通DiSEqC 1.0協議接收機的朋友,筆者建議你們在開始使用TP8801天控器時首先將其清零后再設定軟件東西邊界極限限位。因為這類接收機無法在接收機設置中對天控器進行設置,只能通過天控器的遙控器進行相應操作。大家都知道DiSEqC 1.0協議最少支持4個衛星信號的輸入和切換。實際上如果只有1個高頻頭時也就無需對接收機端口進行設置了,剩下的工作就只是對天控器進行設置操作。

接下來,我們可以使用遙控器進行極軸天線及天控器的軟件邊界設定。先按控制面板上的“E/W”、“W/E”鍵或者遙控器上的左/右轉動鍵驅動推桿至最低(極軸天線東面)或最高(極軸天線西面)位置,在遇到極軸天線推桿硬件物理限位后,天控器會顯示“”。此時向相反方向調節即可進行下一步操作。

再按遙控器上的“Limit”鍵,數碼管顯示“L--”。再按遙控器上的右鍵,數碼管顯示“L.L.”并閃爍。然后再按ENTER鍵3秒確認設置左邊界,此時數碼管顯示“L.L.”不再閃爍。表示已經設定好左(東)邊軟件極限。驅動極軸天線向西邊到達物理限位后再返回部分后按遙控器上的“Limit”鍵,數碼管顯示“L--”。再按遙控器上的左鍵,數碼管顯示“H.L.”并閃爍。然后再按ENTER鍵3秒,確認設置好右(西)邊界,此時數碼管顯示“H.L.”不再閃爍。如此設置后,無論如何向東或向西驅動極軸天線操作都會在推桿物理限位前提示已經到達相應的邊界“.”或者“”,不會顯示出“”。

下一步是將接收機的設置根據實際情況進行調整,比如筆者的四切1開關2輸入為5150MHZ C 波段,3輸入為9750/10600MHZ KU波段。所以把105.5E的鳳凰衛視參數輸入到接收機后,向左(東邊)驅動極軸天線找尋信號。由于室外極軸天線軌跡已經完全調整正確,很快就會出現鳳凰衛視的信號質量,找到信號質量最大值后可以按遙控器“store”鍵,此時數碼管顯示“C- -”。 輸入自定義的星位如01,再按“ERTER”鍵3秒后看到數碼管的“C01” 變成 “P01”,表示存星過程完成。

存完參數之后,就可以搜索衛星節目了。也可以在查看最低信號質量節目后,微調極軸天線,再次保存衛星位置。此后繼續向東找尋108E、115E、122E、134E等衛星,向西找尋100.5E、95E、88E等衛星位置。筆者的極軸天線向東可收下衛星最大角度為166E,向西最大角度為68.5E。

此前安裝調試時,由于筆者對24寸推桿承受力量不甚了解,又缺乏調試經驗,以至于極軸天線安裝位置錯誤,造成推桿負重過載而損壞。極軸天線負載最重的地方就是東西邊界特別是166E和49E。當24寸推桿從166E拉動3米網狀極軸天線時,天線偏地面方向,承受力量非常大,驅動電流同時也遠超正常范圍。如果推桿質量不好,很容易會拉壞螺絲口報廢。最后筆者根據實際使用情況確定了極軸天線推桿的正確安裝位置,而驅動推桿的電流也在正常使用范圍,不會出現24寸推桿在極軸天線右邊安裝時拉動極軸天線那樣超載的巨大力量和過載結果。此時天控器驅動3米天線最大負載從166E改變為68.5E,天線偏向角度減小,也減小了推桿所承受的拉力(我放棄49E以增加極軸天線安全區);如果不這樣調整唯一的辦法就只有將24寸推桿更換為36寸推桿了。

調換星過程如下:通過遙控器上下鍵進行選星,在已選星位號出現約3秒后,數碼管顯示脈沖數字自動驅動推桿到存星位置。該功能為TP8801系列特有功能,無須2次確認。此換星操作最少需要存入2星位置后才有效。也可直接輸入數字星位號如08,數碼管顯示“P08”,然后再按ENTER確認,推桿會走到存星位置,在原位置輸入相同星位則不會動作。使用普通支持DiSEqC 1.0協議接收機配合該天控器極軸天線使用時,換星換臺必須使用到2個遙控器,可以先用天控器的遙控器選換好衛星位置再切換接收機衛星信號,也可以先切換好衛星頻道后再換星,2者缺一不可。

天控器與DM500的配合

目前常用的430xp和DM500S接收機均可支持DiSEqC 1.2極軸協議,配合天控器最為方便,其中DM500S不僅支持 DiSEqC 1.0、1.1、1.2協議,而且也是當前最流行的機器。下面筆者就簡述一下通過DM500S設置該天控器的過程。

1、存儲衛星數據

首先利用原極軸天線天控器把極軸天線驅動到正南中心位置,再把TOPSIGNALTP8801 天控器接入系統。此時可能出現有兩種情況:一是天控器已經存好預收衛星數據時,可以用天控器調星,依次找到所有衛星的數據存入天控器,二次使用時則由DM500S控制天控器自動調星。相當于把天控器內數據copy到DM500S接收機。

二是把TP8801 天控器初始化清零,使用DM500S直接在極軸設置中驅動極軸天線尋找衛星信號,并保存衛星位置和下載節目,這個過程相對于前一種方式更復雜一些,全部衛星位置設置過程所需時間更長。原因很簡單,DM500S(在使用四切一時)反應沒有普通免費機靈敏,找星時會有所延遲,以至于天控器在驅動推桿跑過欲收衛星位置時,還沒有及時反應而延長調試時間。特別是信號較弱的衛星在這個問題上更為突出,需要更長時間才可以搞定。實際上無論哪種方式去尋找衛星信號和存儲衛星位置,都必須使用DM500S的極軸設置功能。

2、調整極軸設置

在首次使用DM500S的 DiSEqC 1.2協議極軸功能之前,要對高頻頭進行設置,方可啟動極軸功能。雖然DM500S接收機有現成的極軸定義下的所有衛星,但是每次設置都很繁瑣,不利于實際操作,所以筆者在《非標準用戶定義設置》菜單中增加新衛星進行極軸設置。

在筆者的極軸天線上,所有C波段衛星統一使用1個5150MHZ本振高頻頭設置,所有KU波段衛星統一使用1個9750、10600MHZ雙本振高頻頭設置。注意在天控器高頻頭設置時不能選擇增加電壓,否則會出現無法正常工作的狀況。DISEqC參數根據個人4切1輸入情況選擇,在DISEqC模式中啟用Version 1.2極軸功能,在頻道搜索中的第3項“極軸設置”功能菜單內就會有相應的極軸關聯選項了。(見圖6-7)

由于筆者在LNB選項中配置了2個高頻頭,所以進入極軸設置時,系統會要求選擇其中1個高頻頭(如圖8)。進入極軸設置選項后可以在使用GOTOXX功能下輸入當地經緯度保存(如圖9),再在極軸配置下的“模式”菜單選擇“位置”,并選擇衛星。轉發器任意選擇一組參數(如圖10),極軸天線的方向則依據DM500S遙控器的左右鍵而改變,若出現控制方向與極軸天線實際動作不一致時,需要把推桿電源正負極調換,相關物理極限也需要調整。

當預收衛星信號SNR AGC數值最高,BER最小的情況下,可以用DM500S對該衛星位置進行存儲,天控器也會作出對應的數據顯示。由于DM500S只支持存儲79個星位,而天控器最高可存儲99個。所以打算用DM500S去驅動極軸天線的用戶必須在79內選擇存儲星位(如圖11)。保存衛星位置后,可以在多星選擇中找出剛才存下的衛星,選擇自動搜索該衛星信號即可。

寫在最后

使用TOPSIGNALTP8801 DiSEqC 1.0、1.2協議 天控器配合SVEC 3M網狀極軸天線1年多來,筆者對其功能頗為滿意,它唯一的缺點就是遙控器按鍵之間的距離太近,按鍵體積太小,在使用時容易發生誤操作,建議廠商在后續產品中予以改進。

>>> 使用天控器的小知識

1、確認東西邊界

DM500S極軸配置下模式的東極限設置可以在最初尋找衛星位置之前進行設置,也可以在最后進行設置。最后進行設置的好處是可以在知道自己最遠可以收下哪顆星后適當偏移后就可以確認。比如筆者的極軸天線可以到達166E,但由于建筑物遮擋后最大角度可以收下146ku,那么我的軟件限位就可以在把天線調動到146E后稍微走動1點估計148E即可保存軟件限位了。下次設置向左(東邊)點動時就會在148E處停止前進。使用時,無須擔心超越極限。根據需要也可以取消或者重新設定東西邊界極限位置。(如圖12-13)

2、無用的選項

DM500S的極軸配置功能選項模式下有多種功能選項,其中在極軸配置模式中重新計算功能基本上無實際應用價值,因為衛星位置信號偏移的原因主要是推桿固定螺母松動,內部絲桿磨損間隙加大等因素造成的。

3、IMG也有差別

DM500S目前使用有PLI、ATM、GE這三種IMG,都有極軸設置功能,且基本通用。唯一有區別的就是部分系統極軸設置中操縱極軸天線向東或者向西時的動作不同。有的系統按遙控鍵1下,極軸天控器只輸出1個脈沖動作,持續按下則繼續走動,松手立即停止運轉。這種DM500S使用的系統在極軸設置時最方便、準確、好用。

另外1種IMG的特點是放開按鍵后,極軸天控器不能立即“剎車”,這樣會帶來錯誤的位置,使信號無法實時顯示,需要多次來回調動極軸天線才能找到最佳位置。

第7篇：sip協議范文

IETF最初制定的是sip會話的初始協議，可以用于多方面的通信。Sip是在應用層控制的協議并且它的基礎是文本，是獨立于底層傳輸協議的。并且，Sip的用途包括：建立、修改和終止IP網上的雙方或多方的通話。這些會話的種類有很多，有多媒體會議、電話呼叫、或者是多媒體會議。Sip壓縮技術支持語音通話，可以不用手動輸入那么麻煩，并且它還可以定位使用者的位置，以便于能夠更快的找到使用者。Sip協議的特點是簡單、易于擴展、能夠很快實現，這些特點被人發掘并且越來越得到人們的重視，所以現在一些科研人員開始研發一些能夠支持和使用Sip壓縮技術的多媒體客戶端。這一項技術如果研發成功的話，它會成為第三網絡和3G多媒體的重要協議。

2Sip壓縮技術在無線通信中的應用

隨著時代的快速發展，人們越來越多的使用無線通信技術，這也就促使了研發Sip壓縮技術的步伐，使得Sip壓縮技術在無線通信上有了很大的應用。

2.1Sip壓縮

Sip是收集在Sip中出現的字符串，并且對這些字符串進行編碼。但是，每個Sip消息的空間中也存在著URI，URI占據了Sip消息中的一些字節空間，這些字節空間有URI的求法，URI中的From和To的字節，還有隱藏在Contact字段中的URI字節。所以，在建立會話的過程中如果出現形成SIPURI的聯系人列表是UA和Proxy之間成立的這種情況的話，那么在建立會話的過程中會對聯系人列表中的URI字節進行維護和編碼，因此，在對每個聯系人消息進行編碼時可以使Sip信息的頭部大小降低。所以，在客戶端和服務器之間創建和維護聯系人列表是Sip壓縮的關鍵。Sip壓縮的前提就是必須對Sip協議進行一定的擴展，在Sip信息的頭部可以增加一些區域，用來對終端支持Sip壓縮或者是對方使用Sip壓縮進行一系列的說明。在滿足Sip中要求的基本機制和特定信令壓縮參數的要求之下可以支持Sip的壓縮，并且可以對Sip信息進行壓縮和解壓。Sip傳輸的端口是5060端口，當使用Sip壓縮是端口依舊是5060端口，而且這兩者會分得很清楚，不會混淆。未壓縮消息字節的高位全為1，所以，要判斷字節是壓縮消息還是原始消息的方法是一個支持Sip壓縮的終端是否可以接收到高5位的消息。如果高5位的值全為1，這是原始消息，這就把這些消息直接交給應用層進行應用；如果高5位的值不全為1這就是壓縮消息，就要把這些消息轉給消息的解壓發生器進行解壓。

2.2Sip擴展

Sip擴展的目的是能夠使Sip壓縮技術更好的實現，可以讓用戶隨意選擇。現在，有兩種方法可以提高Sip整體壓縮的效率：（1）動態壓縮：通過自己本身已經壓縮過的信息來壓縮現在正要壓縮的信息，這樣做的好處是可以節省字節空間。但是，如果要使用自己本身已經發送過的信息，就必須經過壓縮處理器的處理。因為如果信息是在可靠的傳輸層傳送，這就能夠保證信息的質量，但是如果不是在可靠的傳輸層，這就不能夠保證信息的準確性。（2）共享壓縮：通過在壓縮的過程中使用自己本省已經接收到的信息來壓縮自己要發送的信息。這種的壓縮方式在請求的模式中能夠獲得很好的壓縮效果。通過考察Sip協議，可以發現每個用戶一般會產生很多相同的信息，這就意味著Sip壓縮技術在工作的時候壓縮信息的重復度相當高，而且信息冗余度相當高。通常的解決辦法是，如果建立一種含有某些重復性詞語的字典，這樣就會很好地提高壓縮處理器的效率。所以說，在Sip的擴展操作中也應用了可以讓用戶自定義的字典，這樣來使Sip壓縮效率提高。

3結語

第8篇：sip協議范文

關鍵詞:圖書館;流通交換;館際互借;SIP2; NCIP

中圖分類號:G250文獻標識碼:A文章編號:1009-3044(2009)36-10447-03

Library Circulation Exchange Protocol Overview

ZHU Huang-feng

(Aisino Corpration, Beijing 100195, China)

Abstract: Library circulation exchange protocol is different between the library circulation management softwares, as well as the library circulation management software and self-help equipments in library. This paper outlines a number of commonly used library circulation exchange protocol, with an emphasis on the 3M company's SIP2 and the American National Standards Organization NCIP protocols described and compared.

Key words: library; circulation exchange protocol; SIP2; NCIP

隨著圖書館行業的不斷發展和科學技術的不斷進步,圖書館信息化水平也在不斷的提高。到目前為止,絕大部分圖書館已經完成了館藏信息的數據庫管理和流通自動化。同時,圖書館的開放性要求也越來越高,圖書館與圖書館之間館際互借的業務越來越多。

然而,不同圖書館的館藏信息數據庫可能有不同的數據格式,不同圖書館圖書流通管理的業務處理方式也有可能各具特色。如何能確保圖書館與圖書館之間館際互借業務無障礙運行?如何能保證圖書館在更新圖書館流通管理系統或者引進圖書自助借還設備時無需做太多改動?

館際流通交換協議能夠為不同圖書館的圖書流通管理系統提供數據和業務交互提供支持,同時也能為圖書館流通系統和其它系統,如本館其它業務系統、自助借還設備等,之間提供數據和業務交換。

1 常用圖書館流通交換協議簡介

1.1 Z39.50 Item Order

Z39.50協議是一種在客戶服務器環境下計算機與計算機之間進行數據庫檢索與查詢的通訊協議。它能夠為圖書館館藏數據庫提供標準的數據庫檢索與查詢服務,從而推動了圖書館之間聯機查詢、數據共享服務。

Z39.50由NISO(美國國家信息標準組織)提出,經過圖書館行業20多年的推廣與完善,最終為ISO接受成為國際標準。在Z39.50推出第三版時,增加了一個新特性,即可以通過擴展服務實現文獻預訂(Item Order),實現館際互借。這些擴展服務并不是Z39.50協議本身所實現的部分,而是由其它應用系統來實現。Z39.50 Item Order能夠支持簡單的圖書館流通交換,適用于請求一本圖書或文獻、不需要任何附加報文的事務。它的優點是可以基于Z39.50查詢的結果,直接針對其中某本圖書或文獻發起流通請求。

1.2 ISO ILL

ILL(InterLiblary Loan)館際互借協議是關于館際互借協議的國際標準,最初是加拿大國家圖書館為了便于國家網絡信息資源共享而發起的。

ISO ILL協議標準規定了兩個或者多個ILL館際互借應用通過Internet,交互報文,而不用考慮使用的軟硬件情況。協議規定了所交互報文的數量和類型、報文中的數據元素和報文交互的順序。

ISO ILL和Z39.50 Item Order相比,是一個更為復雜、完整的圖書館流通交換協議,它不但可以支持點對點的簡單通訊,而且可以支持鏈狀請求、分布式請求,完成一個跨越請求方、應答方和中間方(可以有一個或多個)的復雜事務。ISO ILL適合于需要進行大量書籍、信息往來的館際互借事務、需要對事務進行統計、控制的圖書館系統,或者是提供館際互借的中間方。

1.3 SIP2協議

SIP2是Standard Interchange Protocol V2.00的簡寫,由3M公司制定,是圖書館自動借還設備與流通管理系統之間的數據傳輸協議。SIP2協議并不是一個完整的圖書館流通交換協議,它是圖書館自助借還設備與流通管理系統之間進行流通信息交換的專用協議。

SIP2協議最初是為了實現3M公司的圖書館自助借還設備Self CheckTM和圖書館流通管理系統之間的信息交換而定義的接口。隨著圖書館自動化的不斷發展以及3M公司產品的推廣、發展,最終成為3M公司在圖書館行業推廣的標準協議。

SIP2協議的推廣有助于圖書館能夠在引進自助借還設備的同時對已有的流通管理系統僅需要做少量甚至不需要修改;有助于圖書館方便地更換自助借還設備或者流通管理系統而不影響到其它系統。

由于3M公司的推動,SIP2協議非常成功,成為圖書館自助式流通服務的事實標準。

1.4 NCIP協議

NCIP(NISO Circulation Interchange Protocol),由美國國家信息標準組織(NISO)制定的關于館際互借的一種協議,也稱Z39.83協議。NCIP的制定,借鑒了3M公司SIP2協議的消息模型和通訊機制,并做了充分的擴展,是一個復雜協議,同時也是至今為止最為強大、完整的圖書館流通交換協議。

NCIP定義和規范了對象集、服務集、支撐這些服務的消息及消息中的元素集,以及控制單個連接中消息交換的狀態表。和SIP2不同,NCIP不僅僅用于圖書館自助借還設備與流通管理系統之間的數據通訊,還能用于圖書館流通管理系統之間、流通管理系統與其它多個應用系統之間的多應用系統環境下系統之間的互操作。

2 SIP2協議分析

2.1 SIP2報文對

SIP2協議定義了一些報文對,每一對報文對由請求報文與響應報文組成,請求報文都是由圖書館自助借還設備主動發起的,響應報文都是由圖書館流通管理系統對請求報文進行處理后作出的響應。任意兩個報文對之間都是相互獨立的,也就是說,圖書館自助借還設備和流通管理系統之間的每一次請求與應答是一個獨立、完整的交易,每一對報文對中包含本次交易所需要的全部信息,而不依賴于其它信息。

2.2 SIP2消息交互模型

由于SIP2每一次報文的請求與響應是一個獨立的事務,因此SIP2協議中每一次消息交互只控制本次報文的請求、請求報文的處理和處理結果響應,不涉及到整個圖書流通生命周期及流通事務的消息傳遞和狀態轉換。SIP2請求方(自助借還設備)和SIP2服務方(圖書流通管理系統)的消息交互模型如圖1所示。

在SIP2消息交互模型中,請求方包含空閑、等待兩種狀態,服務方包含空閑、處理兩種狀態。當SIP2請求方受到外界觸發(自助借還設備受讀者觸發或自助借還設備中設定的程序觸發),SIP2請求方向服務方發送消息,隨后進入等待狀態;SIP2服務方收到請求消息后,轉入處理狀態,當事務處理完畢后向請求方返回響應消息,隨后再次進入空閑狀態;SIP2請求方收到響應消息后,從等待狀態回到空閑狀態。

SIP2請求方和服務方都包含報文校驗功能,即收到消息后首先對消息進行校驗,如果校驗錯誤則要求對方重發;SIP2請求方發送請求消息后,如果一段時間內未收到響應消息,根據設定規則重發或者自動返回空閑狀態。

2.3 SIP2協議的特點

SIP2協議是圖書館自助借還設備和流通管理系統之間進行通訊的專用協議,具有以下特點:

1)實時性。SIP2協議的服務方需要及時響應,SIP2請求方往往會實時地等待處理結果。

2)無會話。SIP2協議的請求方和服務方之間的每一次消息交互都是一個獨立的事務,和前一次及后一次的消息交互彼此獨立、互不影響,雙方不保持會話狀態。

3)簡單。SIP2協議本身僅僅定義了一組報文對格式,并簡單地描述了SIP2請求方和服務方消息交互的模式,協議非常簡單、實用。

4)專用性。SIP2從最初在3M設備及圖書流通管理系統中的應用,到后來作為自助借還業務標準的推廣,都是針對自助借還業務本身的,專用性強,通用性差。

3 NCIP協議分析

3.1 NCIP對象及服務

NCIP協議定義和規范了一個對象集合服務集,以及支撐這些服務的消息、消息中的元素集、控制單個連接中消息交換的狀態表。

NCIP定義了3種對象類型:讀者(User)、圖書(Item)、機構(Agency)。

NCIP定義了3種服務類型:查找服務(Lookup)、更新服務(Update)、通告服務(Notification)。

查找服務包括5種:查找圖書服務、查找讀者服務、查找機構服務、用戶鑒別服務、查找版本服務;

更新服務包括20種,可以分為典型流通事務(圖書請求、借出、續借、催還、歸還等)、對象維護(圖書增加、更新、讀者增加、更新、讀者財務賬戶維護等)、其它;

通知服務業包括20種,和更新服務一一對應,用于對更新服務的結果進行通告。

3.2 NCIP實施框架與應用框架

NCIP將服務和數據對象與實際實施的具體細節分離開來,以確保NCIP能夠長期使用的穩定性,還能夠提供靈活性以適應應用和技術的變化,不必因為新技術的出現而重新定義服務和數據對象。

實施框架:每一種實施方法都在一個獨立的實施框架中描述,這個框架規定消息怎么樣交換。規定的內容包括消息、字符和數據編碼,必須的構件和行為、網絡傳輸、網絡安全等。

應用框架:對于給定的實際環境和規則下的特定應用系統,可以使用應用框架來描述協議的使用方法。應用框架中描述了系統必須支持的服務。對于特定外部事件和條件,他還通過事件表建立起和協議中某種服務的對應關系。

3.3 NCIP消息交互模型

NCIP協議的消息交互模型和SIP2類似。

NCIP只控制一次連接的消息傳遞和狀態轉換,不控制整個流通生命周期的消息傳遞和狀態轉換。NCIP的服務是一種確認,每一個啟動消息都有一個響應消息作為服務的確認,響應方的響應消息在同一個連接中完成。NCIP的傳輸協議可以是TCP/IP、HTTP、HTTPS中的一種或多種。

在NCIP協議的消息交互中,一方是發起方,一方是響應方。和SIP2協議有所區別的是,SIP2協議的消息交換中請求方總是自助借還設備、服務方總是流通管理系統;而NCIP協議消息交互的發起方可以是自助借還設備,也可以是圖書流通管理系統或其它應用系統;圖書流通管理系統可以是一次消息交互中的響應方,也可以是另外一次消息交互中的發起方;對于某一次連接,有且僅有一個發起方和響應方。

3.4 NCIP協議的特點

NCIP協議是一個正在成熟并逐漸占領市場的標準協議,它具有以下特點:

1)實時性。NCIP和SIP2協議一樣,響應方需要及時對發起方的消息進行響應,發起方通常需要實時等待響應消息以便于進行下一步處理。

2)無會話。NCIP協議中的每一次連接完成一個獨立的事務,但不是圖書流通生命周期的全部。NCIP的每一次連接與前一次連接、下一次連接相互獨立,不保持會話狀態。

3)完整性。NCIP協議對圖書流通管理系統之間,以及與自助借還設備之間的圖書流通業務提供了充分的支持,能夠滿足各圖書館之間館際流通業務的需求,也能滿足圖書流通管理系統與自助借還設備之間的流通業務。

4)可擴展性。NCIP將對象、服務的定義與實施細節分開,提供實施框架和應用框架,能夠為圖書館未來流通業務的擴展以及新技術的出現提供充分的擴展性。

5)復雜性。NCIP和現有的其它圖書流通交換協議相比更為復雜,應用范圍更加廣泛,實施的復雜度也相對較大。

4 應用前景分析

Z39.50 Item Order和ISO ILL是傳統的圖書流通交換協議,主要用于各圖書館之間館際互借業務的建設。SIP2協議是在圖書館自助借還出現后,迅速占領市場的專用協議,它實現了圖書館自助借還設備與流通管理系統之間的流通業務交互的標準化,為圖書館迅速引入自助借還服務、推動圖書館服務現代化奠定了基礎。SIP2協議無可非議地成為事實上的自助借還服務的流通交換標準,并將在未來的幾年內繼續占據自助借還設備流通交換協議的主要位置。

另外一方面,隨著軟硬件水平的不斷提高,自助借還設備的功能越來越強大,提供的自助服務越來越豐富,現有的SIP2協議并不能完全滿足未來發展的需求。NCIP協議就是在這樣的條件下誕生并逐步成長的,NCIP協議定位于構建支持圖書館流通管理系統之間,以及與自助借還設備之間完整的流通交換協議,并且支持圖書、讀者、機構的查詢、統計、消息公告等業務。

NCIP協議的技術委員會包含了美國國家圖書館、加拿大國家圖書館,以及OCLC、Ex Libris、SIRSI、3M等圖書館自動化系統軟硬件廠商。SIP2協議的制定者3M公司目前已經是NCIP協議的主要推動者之一,3M公司新的圖書館自助借還設備將支持NCIP協議。NCIP協議的逐步完善和信息技術的不斷發展,必將為NCIP協議的普及推廣迎來更為廣闊的應用前景。

參考文獻:

[1] 胡維青.圖書館集成系統的應用標準[J].棗莊學院學報,2006(2):79-84.

[2] 謝亞勇.幾種館際互借協議之比較與探討[J].上海交通大學學報,2003(S1):53.

[3] 李軍凱.兩種館際互借模式的比較研究[J].圖書館理論與實踐,2005(4):15.

[4] 李軍凱.試論館際互借的模式[J].圖書館工作與研究,2005(3):21-23.

[5] SIP2協議[S].3M公司.

第9篇：sip協議范文

關鍵詞： SIP；IMS；安全

中圖分類號：G434 文獻標識碼：A 文章編號：1671－7597（2012）0210110－01

1 SIP常用的安全機制以及存在的問題

IP多媒體核心系統（IMS）是第三代移動通信合作伙伴項目提出的支持IP多媒體業務的子系統，IMS采用了SIP協議與固定寬帶進軟交換。SIP協議具有接入無關性、支持用戶漫游等優點，為IMS實現網絡融合帶來了前所未有的契機。但是，由于SIP協議是基于IP網絡的實時通信協議，IP網絡的開放性、可獲得性以及廣域性使得SIP應用容易受到攻擊。

目前SIP主要使用2種安全機制：認證和數據加密。HTTP摘要認證是最常用的SIP認證方式。但該認證方式存在著一定的缺陷：

1）只能提供服務器對客戶機的單向認證，容易遭受服務器偽裝攻擊。攻擊者有可能截獲發往服務器的請求，并偽裝成該服務器對客戶機進行認證，此時客戶機無法察覺。

2）摘要算法單一固定。目前用于計算響應值的摘要算法MD5已有被攻破的公開報道，共享密碼在傳輸過程中有被破譯的可能。

3）不具備提供密鑰協商的功能。無法保障認證結束后正常安全的通信。

4）認證過于依賴共享密鑰。密鑰管理方式的選取對認證的可靠性有直接影響。

另外，SIP協議中未直接支持用戶之間媒體流的機密性，我們需要通過實現附加機制以保證竊聽者無法通過竊聽用戶通信數據來獲取用戶信息，從而有效地保護用戶的隱私性和商業秘密。

2 基于SIP的IMS安全性方案設計

考慮到傳統HTTP摘要認證機制以及其他幾種認證機制的局限性，并結合HTIP摘要認證和SIP協議的特點，我們通過擴展和豐富SIP消息頭域的內容，并借鑒丁SRTP協議（Safe Real-time Transport Protocol），對傳統HTTP摘要認證作了改進，設計了一種新的SIP安全方案，初步實現Client和Server之間的雙向身份認證、密鑰協商、媒體流加解密與認證。

2.1 雙向身份認證、密鑰協商過程

為實現雙向身份認證、密鑰協商，則不僅服務器可以向客戶端發送認證，客戶端也要向服務器端發送認證。一次成功的呼叫認證過程如圖1所示。服務器端信息為challenge_s，包括作用域realm_s、隨機數nonce_s、摘要算法H1等。客戶端對challenge_s的響應值response_c是將用戶名username、共享密鑰passwd，隨機數nonce_s、作用域realm_s、客戶端的公鑰v_c按一定規則組合，經H1摘要算法運算后生成。客戶端信息為challenge_c，是由v_c、隨機數nonce_c、摘要算法H2、客戶端支持的加密算法和模式等構成，服務器端對challenge_c的響應值為response_s是將服務器端域名、共享密鑰passwd、v_c、隨機數nonce_c按一定規則組合，經H2摘要算法運算后生成。

該安全機制通過2次呼叫嘗試，實現了雙向認證機制，機制中的摘要算法推薦采用256位SHA1。后續的會話密鑰及加密方式由Server根據Client及自身的支持情況決定，一般情況下采用128位AES及IDEA算法。

2.2 媒體流加解密與認證

SIP協議中未直接支持用戶之間媒體流的機密性，我們需要通過實現附加機制以保證竊聽者無法通過竊聽用戶通信數據來獲取用戶信息。我們使用的媒體數據包頭由4個部分組成，其中Code表明了所采用的視頻/音頻編解碼類型，Flag的第一位指示是否對數據進行了加密，Auth是對序列號、SSRC及媒體數據計算認證值后截取的前32位，SSRC是同步源標識符。對序列號認證可以防止重放攻擊，由主密鑰生成會話密鑰和認證密鑰的過程類似于SRTP中的方法，但用32位的序列號取代了SRTP中的48位Index值。對媒體數據的加解密缺省使用的AES的Counter模式，由會話密鑰根據序列號等信息對每個數據包生成一個密鑰，再用此密鑰對這個數據包中的媒體數據加密。也可以使用呼叫建立過程中協商好的算法和模式。

3 小結

本文介紹了SIP網絡攻擊、常用安全機制及其存在的問題，給出了基于SIP的企業即時通信系統的安全性方案設計。在以后的研究中，將對端到端和逐段轉接的保護機制進行研究，以增強了RTP流的平穩性與抗抖動性，提高網絡帶寬利用率。

參考文獻：

[1]J.Rosenberg and H.Schulzrinne et al, "SIP：session initiation protocol," RFC 3261, Internet Engineering Task Force, June 2002.

[2]H.Schulzrinne, S.Casner, R.Frederick et al,"RTP： A Transport Protocolfor Real-Time Applications", RFC 3550, July 2003.

[3]Gonzalo Camarillo，SIP揭密，人民郵電出版社，2003.