SIPSIP（Session Initiation Protocol）是一個應用層的信令控制協(xié)議。用于創(chuàng)建、修改和釋放一個或多個參與者的會話。這些會話可以是Internet多媒體會議 、IP電話或多媒體分發(fā)。會話的參與者可以通過組播（multicast）、網狀單播（unicast）或兩者的混合體進行通信。

　　SIP與負責語音質量的資源預留協(xié)議（RSVP） 互操作。它還與若干個其他協(xié)議進行協(xié)作，包括負責定位的輕型目錄訪問協(xié)議（LDAP）、負責身份驗證的遠程身份驗證撥入用戶服務 （RADIUS） 以及負責實時傳輸的 RTP 等多個協(xié)議。

　　SIP 的一個重要特點是它不定義要建立的會話的類型，而只定義應該如何管理會話。有了這種靈活性，也就意味著SIP可以用于眾多應用和服務中，包括交互式游戲、音樂和視頻點播以及語音、視頻和 Web 會議。SIP消息是基于文本的，因而易于讀取和調試。新服務的編程更加簡單，對于設計人員而言更加直觀。SIP如同電子郵件客戶機一樣重用 MIME 類型描述，因此與會話相關的應用程序可以自動啟動。SIP 重用幾個現有的比較成熟的 Internet 服務和協(xié)議，如 DNS、RTP、RSVP 等。不必再引入新服務對 SIP 基礎設施提供支持，因為該基礎設施很多部分已經到位或現成可用。

　　對 SIP 的擴充易于定義，可由服務提供商在新的應用中添加，不會損壞網絡。網絡中基于 SIP 的舊設備不會妨礙基于 SIP 的新服務。例如，如果舊 SIP 實施不支持新的 SIP 應用所用的方法/標頭，則會將其忽略。

　　SIP 獨立于傳輸層。因此，底層傳輸可以是采用 ATM 的 IP。SIP 使用用戶數據報協(xié)議（UDP） 以及傳輸控制協(xié)議（TCP），將獨立于底層基礎設施的用戶靈活地連接起來。SIP 支持多設備功能調整和協(xié)商。如果服務或會話啟動了視頻和語音，則仍然可以將語音傳輸到不支持視頻的設備，也可以使用其他設備功能，如單向視頻流傳輸功能。

　　通信提供商及其合作伙伴和用戶越來越渴求新一代基于 IP 的服務。如今有了 SIP（The Session Initiation Protocol 會話啟動協(xié)議），一解燃眉之急。SIP 是不到十年前在計算機科學實驗室誕生的一個想法。它是第一個適合各種媒體內容而實現多用戶會話的協(xié)議，如今已成了 Internet 工程任務組 （IETF） 的規(guī)范。

　　SIP協(xié)議解析與實現

　　SIP協(xié)議是一個基于應用層的會話控制協(xié)議。它可以創(chuàng)建、修改、終止多媒體會話（會議），也可以邀請參與者加入到一個現有的會話。

　　因為SIP是一個基于應用層的協(xié)議，所以它不是一套完整的通訊系統(tǒng)方案，它需要和其它的方案或者協(xié)議結合起來實現整套系統(tǒng)。例如，實時傳輸協(xié)議（RTP）（RFC1889）用來傳輸音視頻等實時的流媒體數據。實時流協(xié)議（RTSP）（RFC2326）用來控制媒體流的傳遞。媒體網關控制協(xié)議（MEGACO）（RFC3015）用來控制PSTN網關。

　　由此可見，SIP協(xié)議應該用來組合其它協(xié)議，從而實現完整的服務。但是，SIP基礎的功能和操作不依賴于其它協(xié)議。

　　SIP（ Session Initiation Protocol ，RFC 3261）是由 IETF （國際互聯網標準制定組織）制定的面向 Internet 會議和電話的信令協(xié)議。SIP是一個應用層的協(xié)議，可以建立，修改或者中止多媒體會話或者呼叫。它是一個基于ASCII的端到端的協(xié)議，它實際上是在因特網上提供“約會”服務。用來實現VoIP的開放協(xié)議，最常用的有三種，SIP、MGCP（Media Gateway Control Protocol）和H.323。

　　SIP協(xié)議是專門為 IP 電話，尤其是結合 Internet 設計的協(xié)議，同傳統(tǒng)的 H.323 協(xié)議相比，SIP 擁有明顯的優(yōu)越性：優(yōu)異的可擴展性--大大提高了系統(tǒng)的處理能力；與 Internet 緊密結合--使通訊更加輕松便捷的；卓越的開放性--不僅能夠對手機、 PDA 等移動設備提供良好的支持，對于在線即時交流、語音和視頻數據傳輸等多媒體應用也能夠很好地完成。

　　SIP協(xié)議的特性和優(yōu)勢

　　與SIP兼容的協(xié)議

　　SIP協(xié)議可以單獨地工作，也可以與下面的協(xié)議一起工作。

　　二第一個例子

　　下面引用RFC3261的例子來說明sip的基本功能，包括：定位終端，發(fā)送通訊請求，協(xié)商會話參數，建立會話和撤銷建立的會話。圖1顯示了用戶Alice和Bob使用SIP交換信息的一個典型的例子（每一個消息用字母F和一個數字來標號，標號的前面有一個簡短的消息類型說明）。在這個例子中，Alice使用一個在她的PC機中的SIP應用程序呼叫Bob，Bob使用他的SIP電話，這個SIP電話登錄了互聯網。同時，請注意兩個SIP代理服務器在Alice和Bob的會話的建立中起到的作用。

　　Alice呼叫Bob是使用他的SIP標識符。SIP標識符是一種URI（Uniform Resource Identifier），稱之為SIP URI。SIP URI格式很象email地址，包含一個用戶名和一個主機名，如：sip:bob@biloxi.com。這里biloxi.com是Bob的SIP服務提供者的域名。Alice的SIP URI是：sip:alice@atlanta.com。SIP也支持安全URI，叫做SIPS URI，例如，sips:bob@biloxi.com。一個向SIPS URI的呼叫使用加密傳輸（也就是TLS）來攜帶從呼叫者到被呼叫者所有的SIP消息。

　　SIP是一個與HTTP協(xié)議很像的，請求／應答式的事務模型。每一個事務最少由一個要完成特定方法或功能的請求，和服務器端的一個應答組成。在這個例子中，這個事務從Alice的軟電話發(fā)送一個INVITE請求到Bob的SIP URI開始。INVITE是一個SIP消息，它表示請求者Alice想與Bob通話。INVITE請求包含一些頭域。頭域被稱為屬性，可以提供關于這個消息的額外信息。關于頭域我們一會兒將會詳細說明它們。圖1中的INVITE信息（F1）可能像這樣：

　　第一行文本是這個請求的方法名（INVITE）。后面的行是多個頭域。這里只列出了最少需要的頭域。先在這里對這些頭域做一個簡要的介紹：

　　Via頭域包含Alice希望收到對于這個請求的應答的地址。也就是她告訴請求的接收者，應答應該發(fā)送到 pc33.atlanta.com。后面的branch參數是這個事務的標識符。

　　To頭域包含一個顯示名（Bob）和一個SIP URI或者SIPS URI，這里是使用的SIP URI（sip:bob@biloxi.com）。這個SIP URI就是這個請求要發(fā)送的目標。

　　From頭域也包含一個顯示名（Alice）和一個SIP URI或者SIPS URI，這里是使用的SIP

　　URI（sip:alice@atlanta.com）來指出請求的發(fā)起人。這個頭域還包含了一個tag參數，這個參數包含了一個隨機字符串（1928301774），這個字符串的數字會被軟電話自動增加，它主要起到鑒別的作用，后面還會說明它。

　　Call-ID頭域包含一個全局唯一標識符來標識這次呼叫。這個標識符使用一個隨即字符串和軟電話所在的主機名（或者IP地址）一起生成。這樣，To頭域、From頭域和Call-ID這三個頭域就可以唯一的確定了Alice和Bob的這條點對點的通信關系，并且將這個通信關系交給一個對話（dialog）來處理了。

　　Cseq頭域（命令序列）包含一個整數和一個方法名字。在這個對話中每一個新的請求都會增加這個整數的值，保證這個數值是有序的。

　　Contact頭域包含一個SIP URI或者SIPS URI指出一個能夠接觸到Alice的直接路由，一般這個SIP URI由用戶名和一個完全限定域名（FQDN）構成。因為許多終端系統(tǒng)沒有注冊域名，所以也可以使用IP地址代替FQDN。Via頭域向對方指出了這個請求的應答應該發(fā)送到哪里，而Contact頭域向對方指出了將來的請求應該發(fā)送到哪里。

　　Max-Forwards頭域限制了在這個請求傳送到目的地的時候最多可以有多少跳。它包含一個整數，在每一跳這個整數都會被減少。

　　Content-Type頭域描述消息體的類型（在這個例子里消息體采用了SDP描述，但是消息體內容沒有給出）。

　　Content-Length頭域指出了消息體的字節(jié)數。

　　在后面我們將完整的介紹SIP頭域（RFC3261第20節(jié)）。

　　在會話中像媒體類型、編碼方式、采樣率等信息都不使用SIP描述，而是在消息體中使用其它會話描述協(xié)議的格式。這個例子中采用了SDP描述（RFC2327）。

　　軟電話不知道Bob或者擁有biloxi.com域名的SIP服務器，它將INVITE請求發(fā)送給為Alice提供服務的域名為atlanta.com的SIP服務器。關于Alice如何獲得atlanta.com SIP服務器的地址，可以使用由Alice的軟電話指定，或者使用DHCP探測到等方式。

　　atlanta.com SIP服務器是一個SIP代理服務器。一個代理服務器接收SIP請求，為請求的發(fā)送者轉發(fā)請求。在這個例子中，代理服務器接收到INVITE請求后發(fā)送一個100應答（Trying）給Alice的軟電話。100應答（Trying）指出這個INVITE請求已經被代理服務器接收到，并且已被經進一步向目的地路由。

　　SIP中的應答使用3位數字表示，每一個編號都表示一個描述短語。這個100應答（Trying）也同樣包含和INVITE請求一樣的To、From、Call－ID、CSeq和Via以及branch參數，這樣可以使Alice的軟電話知道這個應答是對應發(fā)送的INVITE請求的。atlanta.com代理服務器定位出biloxi.com代理服務器（這可能需要通過域名解析服務器（DNS）等實現，后面還會詳細講解）獲得了它的IP地址，并且準備把INVITE請求轉發(fā)給biloxi.com代理服務器。在轉發(fā)請求之前，atlanta.com代理服務器增加了一個額外的Via頭域，這個Via頭域包含自己的地址（這時候這個INVITE請求的第一個Via頭域包含Alice的軟電話的地址）。

　　biloxi.com代理服務器接收到這個INVITE請求，并且也發(fā)送一個100（Trying）應答給atlanta.com代理服務器指出它已經接收到這個INVITE請求，并正在處理這個請求。biloxi.com代理服務器知道Bob的IP地址（這可能需要定位服務），它又在這個INVITE請求中加入了一個新的Via頭域，值為自己的地址，然后它把這個INVITE請求發(fā)送給Bob的SIP電話。

　　Bob的SIP電話接收到這個INVITE請求，發(fā)送一個180（Ringing）應答，同時使用鈴聲通知Bob有一個來自Alice的呼叫，讓Bob決定是否接聽。這個180（Ringing）應答反向經過這兩個代理服務器被發(fā)送到Alice。每一個代理服務器使用Via頭域決定向哪里發(fā)送這個應答，并且把移除它自己添加的Via頭域。這樣，雖然只有初始的INVITE請求發(fā)送的時候使用了DNS服務和定位服務，而這個180（Ringing）應答沒有使用，同時代理服務器也不需要記錄整個通訊的狀態(tài)，但是這個應答還是能夠成功的發(fā)送給請求的發(fā)送者Alice。

　　當alice的軟電話接收到180（Ringing）應答后，它將這個消息告訴給Alice，也許使用一個聲音（彩鈴）或者在Alice的屏幕上顯示一個消息。

　　在這個例子中，Bob決定接聽電話，當他按下接聽按鈕時，他的SIP電話發(fā)送200（OK）應答表示接受了這個呼叫。這個200（OK）應答包含一個消息體，消息體使用SDP描述Bob準備和Alice建立的會話的媒體類型等信息。這樣，Alice和Bob交換了一次SIP信息：Alice用INVITE請求發(fā)送一次給Bob，Bob用200（OK）應答發(fā)送一次給Alice。這個交換實現了基本的協(xié)商能力和簡單的offer/answer模型。如果Bob不希望接聽電話，或者他現在正忙（接聽其它電話），那么他會發(fā)送一個錯誤應答而不是200（OK）應答。一個錯誤應答將不會建立會話。

　　Bob發(fā)送的200（OK）應答可能是這樣的：

　　應答的第一行包含一個應答代碼（200）和一個解釋短語（OK）。其它行就是應答的頭域。Via，To，From，Call-ID和CSeq頭域的值都從INVITE請求拷貝而來（這時候應該有3個Via頭域，分別由Alice的SIP軟電話，atlanta.com代理服務器，和biloxi.com代理服務器添加）。Bob的SIP電話添加一個tag參數到To頭域。以后所有的屬于這個對話的請求和應答都要包含這個tag參數。

　　當Alice的軟電話接收到這個200（OK）應答后，馬上停止響鈴并顯示呼叫已經被接聽了。最后，Alice發(fā)送一個確認信息（ACK）給Bob的SIP電話，表示自己收到了最終應答（200（OK））。這個例子中的最終應答由Alice直接發(fā)送給了Bob，這是因為Alice的軟電話從Contact頭域里面可以得到Bob的地址信息。通過INVITA/200/ACK的三步握手，SIP會話就建立起來了。關于SIP會話建立的詳細步驟請參看RFC3261第13節(jié)。

　　現在Alice和Bob的多媒體會話已經建立起來了，他們可以發(fā)送通過SDP協(xié)商好的格式的媒體數據了。一般來說，媒體數據包的傳輸與SIP消息的傳輸采用不同的通信方式。SIP消息大多通過代理服務器轉發(fā)，而媒體數據多使用點對點的傳輸。

　　在會話過程中，無論是Alice還是Bob決定改變這個媒體會話，都要通過發(fā)送一個re-INVITE請求。這個re-INVITE請求包含新的媒體描述（可能是SDP），它不會建立新的會話，而是修改當前已經存在的會話。對方接收到這個請求后，發(fā)送一個200（OK）同意這個改變，最后請求者發(fā)送ACK。如果對方不同意這個修改，可能會發(fā)送一個錯誤應答，比如488（不接受）。但是這個失敗應答不會使已存在的會話退出，而是繼續(xù)使用以前協(xié)商的媒體進行通信。關于修改一個會話的詳細說明，請參看RFC3261第14節(jié)。

　　最后，Bob發(fā)送BYE消息掛斷電話。BYE消息直接發(fā)送到Alice的軟電話。Alice發(fā)送200（OK）確定接收到了BYE消息，并且終止這個會話。Bob不用發(fā)送ACK，因為ACK只有在接收到對INVITE的應答時才被發(fā)送。關于終止一個會話更詳細的說明，請參看RFC3261第15節(jié)。還有一個問題就是關于biloxi.com服務器如何獲得Bob的位置。Bob的SIP電話開機的時候會向一個注冊服務器發(fā)送REGISTER消息。REGISTER消息的作用是將Bob的SIP URI或者SIPS URI與Bob當前使用的電話地址進行幫定，并將這個幫定信息保存到數據庫中，這被稱之為定位服務（location service）。biloxi.com代理服務器使用定位服務獲得Bob的地址。注冊服務器、代理服務器、定位服務器都是邏輯上的服務器，而不是物理上的服務器，所以他們可以位于同一臺服務器上。