1、概述

1.1 SIP概念

      會話初始協議SIP（Session Initiation Protocol）是一個應用層的控制協議，可以建立、修改和結束多媒體的會話。它是由IETF提出並主持研究的一個在IP網路上進行多媒體通訊的應用層控制協議，它被用來建立、修改、和終結一個或多個參加者參加的會話程序。這些會話包括Internet多媒體會議、Internet電話、遠端教育以及遠端醫療等。即所有的因特網上互動式兩方或多方多媒體通訊活動，統稱為多媒體會話。參加會話的成員可以通過組播方式、單播聯網方式或者兩者結合的方式進行通訊。
      總的來說，SIP能夠支援下列五種多媒體通訊的信令功能：

          User location（使用者定位）：確定參加通訊的終端使用者的位置
          User capabilities（使用者能力）：確定通訊的媒體型別和引數
          User availability（使用者的可用性）：決定被叫方是否願意參加通訊
          Call setup（呼叫建立）：振鈴，在主叫和被叫直接建立呼叫的引數
          Call handling（呼叫處理）：包括來電轉駁和終止

2、協議訊息

2.1 訊息型別

      SIP訊息基於10646文字編碼，且不區分大小寫字元，分為請求訊息和響應訊息。

• 請求訊息

• 響應訊息

 2.2 訊息結構

2.3 訊息引數

      請求訊息和響應訊息都包括SIP頭欄位和SIP訊息欄位。SIP請求命令由起始行、訊息頭和訊息體組成，通過換行符區分訊息頭中的每一條引數行。對於不同的請求訊息，有些引數可選。

• Call-ID

Call-ID：本地標識@主機

            示例：

            其中， call-837575-3是全域性唯一的本地標識，192.168.1.13是主機的IP地址。

•  From

            該欄位稱為命令序號。客戶在每個請求中應加入此欄位，它由命令名稱和一個十進位制序號組成，該序號有請求客戶端選定，在Call-ID範圍內唯一確定。序號初值可為任意值，其後具有相同的Call-ID值，但不同命令名稱、訊息體的請求，其Cseq序號應加1。重發的訊息序號保持不變。伺服器將請求中的序號複製到響應訊息中，將請求和其觸發的響應關聯。一般格式為：

Cseq：序號 命令名稱

            示例：

 Cseq：2426 INVITE

            所有的請求和響應必須包含此欄位，以指示請求的發起者。伺服器將此欄位從請求訊息複製到響應訊息。一般格式為：

From：顯示名<SIP-URI>;tag=xxxx

            示例：

From：<sip:[email protected]>;tag=1c17a5

            其中，顯示名為使用者介面上顯示的字元，如果系統不予顯示，應置顯示名為匿名。tag稱為標記，為16進位制數字串，中間可帶連線符‘-’，且該置必須全域性唯一。

•  To

            該欄位指明請求的接收者，格式與From相同，僅第一個關鍵詞用To替代From。

•  Cseq

            該欄位稱為命令序號。客戶在每個請求中應加入此欄位，它由命令名稱和一個十進位制序號組成，該序號有請求客戶端選定，在Call-ID範圍內唯一確定。序號初值可為任意值，其後具有相同的Call-ID值，但不同命令名稱、訊息體的請求，其Cseq序號應加1。重發的訊息序號保持不變。伺服器將請求中的序號複製到響應訊息中，將請求和其觸發的響應關聯。一般格式為：

Cseq：序號 命令名稱

            示例：

 Cseq：2426 INVITE

•  Via

           該欄位用於指示請求歷經的路徑。它可以防止請求訊息傳送產生環路，並確保響應和請求訊息選擇同樣的路徑，以保證通過防火牆或滿足其它特定的選路要求。發起請求的客戶必須將其自身的主機名或網路地址插入請求的Via欄位，如果未採用預設埠號，還需插入此埠號。在請求前傳過程中，每個代理伺服器必須將其自身地址作為一個新的Via欄位加在已有的Via欄位之前。如果代理伺服器收到一個請求，發現其自身地址位於Via頭部中，則必須回送響應“檢測到環路”。
            當請求訊息通過NAT（如防火牆等）時，請求的源地址和埠號可能被改變，此時Via欄位就不能成為響應訊息選路的依據。為了防止這一點，代理伺服器應校驗頂端Via欄位，如果發現其值和代理伺服器檢測到的前站地址不符，則應在該Via欄位中加入“receive”引數，如此修改後的欄位稱為“接收方標記Via頭部欄位”。例如：

Via:SIP/2.0/UDP softx3000.bell-telephone.com:5060
Via:SIP/2.0/UDP 10.0.0.1:5060;received=191.169.12.30 

            代理伺服器或UAC收到Via頭部欄位時的處理規則是：
1、第1個Via頭部欄位應該指示本代理伺服器或UAC。如果不是，丟棄該訊息，否則，刪除該Via欄位。
2、如果沒有第2個Via頭部欄位，則該響應已經到達目的地。否則繼續做如下處理。
3、如果第2個頭部欄位包含“maddr”引數，則按該引數指示的多播地址傳送響應，埠號由“傳送方”引數指明，如未指明，就使用埠號5060。響應的生存期應置為“生存期(ttl)”引數指定的值，如未指明，則置為1。
4、如果第2個Via欄位不包含“maddr”引數，但有一個接收方標記欄位，則應將該響應發往“received”引數指示的地址。
5、如果既無“maddr”引數又無標記，就按傳送方引數指示的地址傳送響應。

            Via欄位的一般格式為：

Via：傳送協議 傳送方；隱藏引數；生存期引數；多播地址引數；接收方標記，分支引數

             其中，傳送協議格式為：協議名/協議版本/傳送層，協議名和協議版本的預設值分別為SIP和UDP。傳送方為通常的傳送方主機和埠號。隱藏引數就是關鍵詞hidden，如有此引數，表示該欄位已由上游代理予以加密，以提供隱私服務。多播地址引數和接收方標記的意義如前所述。生存期引數與多播地址引數配用。分支引數用於代理伺服器並行分發請求時標記各個分支，當響應到達時，代理可判定是哪一分支的響應。
             簡單來說，就是請求時一層一層在開頭新增主機名或地址，響應時一層一層剝離地址。

•  Contact

              該欄位用於INVITE、ACK和REGISTER請求以及成功響應、呼叫進展響應和重定向響應訊息，其作用是給出和使用者直接通訊的地址。INVITE和ACK請求中的Contact欄位指示該請求發出的位置，這樣被叫可以直接將請求發往該地址，而不必藉助Via欄位經由一系列代理伺服器返回。對INVITE請求的成功響應訊息可包含Contact欄位，它使其後SIP請求（如ACK請求）可直接發往該欄位給定的地址。該地址一般是被叫主機的地址，如果該主機位於防火牆之後，則為代理伺服器地址。
對應於INVITE請求的呼叫進展響應訊息中包含的Contact欄位的含義和成功響應訊息相同。但是，CANCEL請求不能直接發往該地址，必須沿原請求傳送的路徑前傳。
REGISTER請求中的Contact欄位指明使用者可達位置。該請求還定義了通配Contact欄位“*”，它只能和值為0的“失效”欄位配用，表示去除某使用者的所有登記。Contact欄位也可設定“失效”引數（任選），給定登記的失效時間。如果沒有設定該引數，則用“失效”欄位值作為其預設值。如果兩者均無，則認為SIP URI的失效時間為1小時。
              REGISTER請求的成功響應訊息中的Contact欄位返回該使用者當前可達的所有位置。
              重定向響應訊息，如使用者臨時遷移、永久遷移、地址模糊等訊息中的Contact欄位給出供重試的其它可選地址，可用於對BYE、INVITE和OPTIONS請求的響應訊息。
              Contact欄位的一般格式為：
                            Contact：地址；q引數；動作引數；失效引數；擴充套件屬性
              其中，地址的表示形式和To，From欄位相同。q引數，其取值範圍為[0，1]，指示給定位置的相對優先順序。數值越大，優先順序越高。動作引數僅用於REGISTER請求。它表明希望伺服器對其後至該客戶的請求進行代理服務還是重定向服務。如果未含此引數，則執行動作取決於伺服器的配置。失效引數指明URI的有效時間，可用秒錶示，也可用SIP日期表示。擴充套件屬性就是副檔名。
              Contact欄位的示例為：
                            Contact: <Sip:[email protected]:5061>;q=0.7;expires=3600

• Max-Forwards

               該欄位用於定義一個請求到達其目的地址所允許經過的中轉站的最大值。請求每經過一箇中轉站，該值減1。如果該值為0時該請求還沒有到達其目的地址，伺服器將回送“483”(Too Many Hops)響應並終止這個請求。
              設定該欄位的目的主要是為了出現環路時不會一直消耗代理伺服器的資源。該欄位的初始值為70。
              Max-Forwards欄位的一般格式為：
                            Max-Forwards:十進位制整數

• Allow

              該欄位給出代理伺服器支援的所有請求訊息型別列表。

              Allow欄位的示例：
                            Allow: INVITE, ACK, OPTIONS, CANCEL, BYE

• Content-Length

              該欄位表示訊息體的大小，為十進位制值。應用程式使用該欄位表示要傳送的訊息體的大小，而不考慮實體的媒體型別。如果使用基於流的協議（如TCP協議）作為傳輸協議，則必須使用此訊息頭欄位。
              訊息體的長度不包括用於分離訊息頭部和訊息體的空白行。 Content-Length值必須大於等於0。如果訊息中沒有訊息體，則Content-Length頭欄位值必須設為0。
              SDP用於構成請求訊息和2xx響應訊息的訊息體。
              Content-Length欄位的一般格式為：
                            Content-Length：十進位制值
              Content-Length欄位的示例：
                            Content-Length: 349
              表示訊息體的長度為349個位元組。

•  Content-Type

              Content-Type欄位表示傳送的訊息體的媒體型別。如果訊息體不為空，則必須存在Content-Type 頭欄位。如果訊息體為空且Content-Type 頭欄位存在，則表示此型別的訊息體長度為0 （如一個空的聲音檔案）。
              Content-Type欄位的示例：
                            Content-Type: application/sdp

• Supported

              SIP協議中定義的100類臨時響應訊息的傳輸是不可靠的，即UAS傳送臨時響應後並不能保證UAC端能夠接受到該訊息。
              如果需要在該響應訊息中攜帶媒體資訊，那麼就必須保證該訊息能夠可靠的傳輸到對端。100rel擴充套件為100類響應訊息的可靠傳輸提供了相應的機制。100rel新增加對臨時響應訊息的確認請求方法：PRACK。
              如果UAC支援該擴充套件，則在傳送的訊息中增加Supported:100rel頭域和欄位。如果UAS支援該擴充套件，則在傳送100類響應時增加Require:100rel頭域和欄位。UAC收到該響應訊息後需要向UAS傳送PRACK請求通知UAS已收到該臨時響應。UAS向UAC傳送對PRACK的2XX響應訊息結束對該臨時響應的確認過程。
              如果某一UA想要在傳送的臨時響應訊息中攜帶SDP訊息體，那麼UAC和UAS都必須支援和使用100rel擴充套件以保證該訊息的可靠傳輸。
              舉例：
                            Supported: 100rel

• User-Agent

              User-Agent頭欄位包含有發起請求的使用者終端的資訊。
              顯示使用者代理的軟體版本資訊可能會令使用者在使用有安全漏洞的軟體易受到外界攻擊，因此，應該使User-Agent頭欄位成為可選配置項。
              舉例：
                            User-Agent: Softphone Beta1.5

• Expires

              Expires頭欄位指定了訊息（或訊息內容）多長時間之後超時。
              舉例：
                            Expires: 5

• Accept-Language

              Accept-Language頭欄位用在請求訊息中，表示原因短語、會話描述或應答訊息中攜帶的狀態應答內容的首選語言型別。如果訊息中沒有Accept-Language頭欄位，則伺服器端認為客戶端支援所有語言。
              舉例：
                            Accept-Language: en

• Authorization

              Authorization欄位包含某個終端的鑑權證書。

3、訊息流程

              使用者每次開機時都需要向伺服器註冊，當SIP Client的地址發生改變時也需要重新註冊。註冊資訊必須定期重新整理。具體流程參考SIP協議詳解。

4、exosip用法分析

              以exosip原始碼中的示例程式分析，流程如下：

//初始化
  context_eXosip = eXosip_malloc ();
  if (eXosip_init (context_eXosip)) {
    syslog_wrapper (LOG_ERR, "eXosip_init failed");
    exit (1);
  }
  if (eXosip_listen_addr (context_eXosip, IPPROTO_UDP, NULL, port, AF_INET, 0)) {
    syslog_wrapper (LOG_ERR, "eXosip_listen_addr failed");
    exit (1);
  }

  if (localip) {
    syslog_wrapper (LOG_INFO, "local address: %s", localip);
    eXosip_masquerade_contact (context_eXosip, localip, port);
  }

  if (firewallip) {
    syslog_wrapper (LOG_INFO, "firewall address: %s:%i", firewallip, port);
    eXosip_masquerade_contact (context_eXosip, firewallip, port);
  }

  eXosip_set_user_agent (context_eXosip, UA_STRING);

  if (username && password) {
    syslog_wrapper (LOG_INFO, "username: %s", username);
    syslog_wrapper (LOG_INFO, "password: [removed]");
    if (eXosip_add_authentication_info (context_eXosip, username, username, password, NULL, NULL)) {
      syslog_wrapper (LOG_ERR, "eXosip_add_authentication_info failed");
      exit (1);
    }
  }

  {
    osip_message_t *reg = NULL;
    int i;

    regparam.regid = eXosip_register_build_initial_register (context_eXosip, fromuser, proxy, contact, regparam.expiry * 2, &reg);
    if (regparam.regid < 1) {
      syslog_wrapper (LOG_ERR, "eXosip_register_build_initial_register failed");
      exit (1);
    }
    i = eXosip_register_send_register (context_eXosip, regparam.regid, reg);
    if (i != 0) {
      syslog_wrapper (LOG_ERR, "eXosip_register_send_register failed");
      exit (1);
    }
  }


//處理

   for (;;) {
    eXosip_event_t *event;

    if (!(event = eXosip_event_wait (context_eXosip, 0, 1))) {
      osip_usleep (10000);
      continue;
    }

    eXosip_automatic_action (context_eXosip);
    switch (event->type) {
    case EXOSIP_REGISTRATION_SUCCESS:
      syslog_wrapper (LOG_INFO, "registrered successfully");
      break;
    case EXOSIP_REGISTRATION_FAILURE:
      regparam.auth = 1;
      break;
    default:
      syslog_wrapper (LOG_DEBUG, "recieved unknown eXosip event (type, did, cid) = (%d, %d, %d)", event->type, event->did, event->cid);

    }
    eXosip_event_free (event);
  }

              eXosip_malloc、eXosip_init等初始化SIP連結的一些記憶體和引數，這些都是直接呼叫原始碼，可以直接沿用。下面的處理流程，是解析伺服器下發的報文，並按列舉巨集的形式分別處理。

              總體來說，exosip呼叫的邏輯比較清晰，原始碼鑽研的意義對本人來說意義不大，所以能寫的比較少，就這樣貼出來做一個參考吧。