調査と解説

メッセージが SIP プロキシを経由するごとに Via ヘッダがメッセージに追加され，ルーティング経路などがわかるようになっている．

メッセージの本体の形式は SIP のドキュメントにおいてはきめられていない． すなわち，内容は自由にきめることができる． しかし，通常 INVITE メッセージやその応答においては，1998 年 4 月に IETF のドキュメント RFC 2327 (M. Handley, V. Jacobson: SDP: Session Description Protocol) において標準化され，2003 年 9 月現在もインターネット・ドラフト draft-ietf-mmusic-sdp-new-14 (M. Handley, V. Jacobson, C. Perkins: SDP: Session Description Protocol) において改訂作業がつづけられているプロトコル SDP (セッション記述プロトコル, Session Description Protocol) が使用される． SDP によってそのセッションにおいて使用されるメディアの型やコーデックなどが指定される． すなわち，SDP による記述内容をみれば，そのセッションがエンコードされた音声だけを使用するのか，音声と動画を使用するのかなどがわかる． SDP を使用した交渉によってユーザエージェント間でメディア通信に必要な情報を交換する方法が “offer/answer モデル” として RFC 3264 (J. Rosenberg, H. Schulzrinne: An Offer/Answer Model with the Session Description Protocol (SDP)) によって標準化されている．

SIP におけるメッセージの例をインターネット・ドラフト draft-ietf-sipping-basic-call-flows-02 (A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers: Session Initiation Protocol Basic Call Flow Examples) から引用する．

   INVITE sip:bob@biloxi.example.com SIP/2.0 
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 
   Max-Forwards: 70 
   From: Alice ;tag=9fxced76sl 
   To: Bob  
   Call-ID: 3848276298220188511@atlanta.example.com 
   CSeq: 1 INVITE 
   Contact:  
   Content-Type: application/sdp 
   Content-Length: 151 
    
   v=0 
   o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 
   s=- 
   c=IN IP4 192.0.2.101 
   t=0 0 
   m=audio 49172 RTP/AVP 0 
   a=rtpmap:0 PCMU/8000 

このメッセージは Alice から Bob への INVITE メッセージである． メッセージの本体は SDP によって記述されていて，メディアとして RTP プロトコルによるオーディオ信号を使用し，その通信に Alice が IPv4 アドレス 192.0.2.101 を使用することなどが記述されている．

4. 要求メッセージの種類

SIP の要求メッセージにおいて指定することができるメソッド名として，前記の RFC 3261 において規定されたものはつぎの 6 種類だけである．

(1) REGISTER

ユーザエージェントを登録する際に送信される．REGISTER メッセージの例を前記の draft-ietf-sipping-basic-call-flows-02 から引用する (最後に空行があることに注意．以下同様)．

   REGISTER sips:ss2.biloxi.example.com SIP/2.0 
   Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7 
   Max-Forwards: 70 
   From: Bob ;tag=a73kszlfl 
   To: Bob  
   Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com 
   CSeq: 1 REGISTER 
   Contact:  
   Content-Length: 0 

このように，REGISTER メッセージにおいては送信元 (From ヘッダ) にも受信先 (To ヘッダ) にもそのメッセージの送信者の SIP URI を使用する．

(2) INVITE

通信開始を要求する際に送信される． 例は前節に示した．

(3) ACK

通信開始が成立した際，すなわち INVITE メッセージに対して成功応答がかえされた際などに送信される． ACK メッセージを送信する目的は，UDP のような信頼性のひくいトランスポート・プロトコルが使用されているときでも高信頼の通信がおこなえるようにすることである． すなわち，INVITE メッセージに対する応答がとどかないときには，INVITE メッセージ送信側は INVITE メッセージを再送しつづけ，受信側は ACK メッセージがとどくまで応答メッセージ (たとえば 200 OK) を再送しつづける． ACK メッセージの例を前記の draft-ietf-sipping-basic-call-flows-02 から引用する．

   ACK sip:bob@biloxi.example.com SIP/2.0 
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 
   Max-Forwards: 70 
   From: Alice ;tag=9fxced76sl 
   To: Bob ;tag=8321234356 
   Call-ID: 3848276298220188511@atlanta.example.com 
   CSeq: 1 ACK 
   Content-Length: 0 

ACK メッセージの形式は要求メッセージとひとしく，要求メッセージに分類されているが，返事を必要としないので 要求-応答 プロトコルの基本からははずれている．

(4) BYE

通信終了の際に送信される． INVITE を送信した側，受信した側のいずれが送信してもよい． BYE メッセージの例を前記の draft-ietf-sipping-basic-call-flows-02 から引用する．

   BYE sip:alice@client.atlanta.example.com SIP/2.0 
   Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 
   Max-Forwards: 70 
   From: Bob ;tag=8321234356 
   To: Alice ;tag=9fxced76sl 
   Call-ID: 3848276298220188511@atlanta.example.com 
   CSeq: 1 BYE 
   Content-Length: 0 

(5) CANCEL

すでに送信したメッセージを取り消す際に送信される． CANCEL メッセージの例を前記の draft-ietf-sipping-basic-call-flows-02 から引用する．

   CANCEL sip:bob@biloxi.example.com SIP/2.0 
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 
   Max-Forwards: 70 
   From: Alice ;tag=9fxced76sl 
   To: Bob 
   Route: 
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 CANCEL
   Content-Length: 0 

このメッセージによって，指定された Call ID をもつセッションがキャンセルされる．

(6) OPTIONS

サーバにその能力を問い合わせる際などに送信される． ユーザエージェントどうしの能力問い合わせにも使用することができる． ??? 節においてのべるように TLS (Transport Layer Security) を使用して SIP による通信をセキュア化するときには OPTIONS メッセージが重要な役割をはたす． CANCEL メッセージの例を 2003 年 1 月に発行された IETF 標準 RFC 3329 (J. Arkko, V. Torvinen, G. Camarillo, A. Niemi, T. Haukk: Security Mechanism Agreement for the Session Initiation Protocol (SIP)) から引用する (ただし，ここでは一部のヘッダが省略されている)．

   OPTIONS sip:proxy.example.com SIP/2.0
   Security-Client: tls
   Security-Client: digest
   Require: sec-agree
   Proxy-Require: sec-agree 

このメッセージは，クライアントがもつセキュリティ機構として TLS とダイジェスト認証とがあることと，セキュリティ機構に関してサーバとの間で合意が必要であることをあらわしている．

(7) PRACK (Provisional Response ACKnowledgment)

PRACK はプロビジョナルな応答の信頼性をたかめるために導入されたメソッドである． PRACK メソッドは前記の RFC 3261 と同時に発行された IETF 標準 RFC 3262 (J. Rosenberg, H. Schulzrinne: Reliability of Provisional Responses in the Session Initiation Protocol (SIP)) において定義されている． すなわち，??? 節で示す応答メッセージのなかで，最終的な応答に関しては信頼性のひくいトランスポート・プロトコル (UDP) を使用するときでも高信頼性がえられるように前記の RFC 3261 においてプロトコル・シーケンスがきめられている． しかし，プロビジョナルな応答は途中で失われたままになることがある． この問題を解決するためのメソッドが PRACK である． PRACK は最終的な応答に対する ACK と同様の役割をはたす． すなわち，PRACK を使用する場合には 100 Trying，180 Ringing などのプロビジョナルな応答に対して PRACK を返信するが，それが応答元にとどかないあいだ前記のプロビジョナルな応答を再送しつづける．

(8) SUBSCRIBE

特定のイベントを指定してその通知を予約するメソッドであり，前記の RFC 3261 と同時に発行された IETF 標準 RFC 3265 (A. B. Roach: Session Initiation Protocol (SIP)-Specific Event Notification) において定義されている． イベントとしてはたとえば通信相手の状態変化 (メッセージを受信できる状態になったとか不在になったとか) などがある． SUBSCRIBE メッセージの例をインターネット・ドラフト draft-ietf-sip-publish-00 (A. Niemi 編: Session Initiation Protocol (SIP) Extension for Event State Publication) から引用する．

      SUBSCRIBE sip:presentity@domain.com SIP/2.0
      Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bKnashds7
      To: 
      From: ;tag=12341234
      Call-ID: 12345678@10.0.0.1
      CSeq: 1 SUBSCRIBE
      Expires: 3600
      Event: presence
      Contact: 
      Content-Length: 0 

ここで先頭行の sip:presentity@domain.com がイベントを発生するエンティティであり，イベントの種類は Event: ヘッダに記述されている presence である． presence イベントは 2003 年 1 月に発行されたインターネット・ドラフト draft-ietf-simple-presence-10.txt (J. Rosenberg: A Presence Event Package for the Session Initiation Protocol (SIP)) において定義されている． 前記のメッセージによって presence イベントの通知を予約している．前記の例においては，watcher というユーザが presentity というユーザのプレゼンスの通知をもとめている． すなわち，presentity がオンライン (在) になる，オフライン (不在) になるなどのイベントの通知をもとめている．

(9) NOTIFY

通知予約されたイベントが発生したときに，イベント発生の事実を予約者につたえるためのメソッドであり，前記の RFC 3265 において定義されている． 前記の例でいえば，通信相手がメッセージを受信できるようになったときや不在になったときに NOTIFY メッセージが送信される． NOTIFY メッセージの例を前記のインターネット・ドラフト draft-ietf-sip-publish-00 から引用する．

      NOTIFY sip:presentity@domain.com SIP/2.0
      Via: SIP/2.0/UDP pa.domain.com;branch=z9hG4bK8sdf2
      To: ;tag=12341234
      From: ;tag=abcd1234
      Call-ID: 12345678@10.0.0.1
      CSeq: 1 NOTIFY
      Event: presence
      Subscription-State: active; expires=3599
      Content-Type: application/cpim-pidf+xml
      Content-Length: ...

      <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
                entity="pres:presentity@domain.com">
         <tuple id="mobile-phone">
            <status>
               <basic>open</basic>
            </status>
            <timestamp>2003-02-01T16:49:29Z</timestamp>
         </tuple>
         <tuple id="desktop">
            <status>
               <basic>open</basic>
            </status>
            <timestamp>2003-02-01T12:21:29Z</timestamp>
         </tuple>
      </presence>

ここでは (通信相手である) presentity のプレゼンスすなわち在・不在などの情報が XML の形式で送付されている． イベントの種類は SUBSCRIBE メソッドと同様に Event: ヘッダに記述され，ここでは presence である．

(10) MESSAGE

すなわち，RFC 3428 (B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle ed.: Session Initiation Protocol (SIP) Extension for Instant Messaging) において定義された，SIP 拡張によってテキスト・メッセージ (インスタント・メッセージ) を送信するためのメソッドである (これは SIP の基本セットにはふくまれない)． MESSAGE メッセージは INVITE メッセージによってセッションが確立されてはいない相手に対しても送信することができる． すなわち，MESSAGE メッセージの送信によってセッションが開始されることがある． MESSAGE メッセージの例を前記の RFC 3428 から引用する．

   MESSAGE sip:user2@domain.com SIP/2.0
   Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse
   Max-Forwards: 70
   From: sip:user1@domain.com;tag=49583
   To: sip:user2@domain.com
   Call-ID: asd88asd77a@1.2.3.4
   CSeq: 1 MESSAGE
   Content-Type: text/plain
   Content-Length: 18

   Watson, come here.

ここではメッセージの内容として “Watson, come here.” があたえられている．

5. 応答メッセージの種類

応答メッセージはプロビジョナルな応答 (provisional response) と最終的な応答 (final response) に分類され，最終的な応答はさらに成功応答，リダイレクション応答，要求失敗応答，サーバ・エラー応答，大域エラー応答に分類されている． これらのうちプロビジョナルな応答は臨時に送信されるものであり，あとであらためて最終的な応答がおくられる．

(1) プロビジョナル (1xx)

100 番台の応答メッセージは付加的な情報をあたえるプロビジョナル (provisional)・メッセージである． プロビジョナル・メッセージとしてはつぎのものが前記の RFC 3261 において定義されている: “100 Trying” (試行中)，“180 Ringing” (呼び出し中)，“181 Call Is Being Forwarded” (転送中)，“182 Queued” (処理待ち中)，“183 Session Progress” (セッションが進行した)． メッセージの形式はつぎに示す成功メッセージと同様なので，例は省略する．

(2) 成功 (2xx)

200 番台の応答メッセージは要求が成功したことをあらわす成功メッセージである． 前記の RFC 3261 において定義されているのは “200 OK” だけである． REGISTER メッセージに対する 200 OK メッセージの例を前記の draft-ietf-sipping-basic-call-flows-02 から引用する．

   SIP/2.0 200 OK 
   Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7 
    ;received=192.0.2.201 
   From: Bob ;tag=ja743ks76zlflH 
   To: Bob ;tag=37GkEhwl6 
   Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com 
   CSeq: 2 REGISTER 
   Contact: ;expires=3600 
   Content-Length: 0  

ここではメッセージの内容は空である． また，INVITE メッセージに対する 200 OK メッセージの例を前記の draft-ietf-sipping-basic-call-flows-02 から引用する．

   SIP/2.0 200 OK 
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 
    ;received=192.0.2.101 
   From: Alice ;tag=9fxced76sl 
   To: Bob ;tag=8321234356 
   Call-ID: 3848276298220188511@atlanta.example.com 
   CSeq: 1 INVITE 
   Contact:  
   Content-Type: application/sdp 
   Content-Length: 147 
    
   v=0 
   o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 
   s=- 
   c=IN IP4 192.0.2.201 
   t=0 0 
   m=audio 3456 RTP/AVP 0 
 

ここではメッセージの内容が SDP によって記述されていて，メディアとして RTP プロトコルによるオーディオ信号を使用し，その通信に Bob が IPv4 アドレス 192.0.2.201 を使用することなどが記述されている． この SDP メッセージは RFC 3264 に記述された offer/answer モデルにしたがっている．

(3) リダイレクション (3xx)

300 番台の応答メッセージは，ユーザエージェントに要求先の変更をもとめるリダイレクション・メッセージである． リダイレクション・メッセージとしてはつぎのものが前記の RFC 3261 において定義されている: “300 Multiple Choices” (複数のリダイレクト候補あり), “301 Moved Permanently” (恒久的に場所を移動), “302 Moved Temporarily” (一時的に場所を移動), “305 Use Proxy” (SIP プロキシ使用要求), “380 Alternative Service” (指定されたサービスは利用できないが代替サービスが存在)．

(4) 要求失敗 (4xx)

400 番台の応答メッセージは要求が失敗したことをあらわす要求失敗メッセージ (クライアント・エラー・メッセージ) である． 要求失敗メッセージとしてはつぎのものが前記の RFC 3261 において定義されている: “400 Bad Request” (不正な要求), “401 Unauthorized” (権限不足), “402 payment Required” (要支払), “403 Forbidden” (禁止), “404 Not Found” (発見できず), “405 Method Not Allowed” (メソッド使用禁止), “406 Not Acceptable” (受理不能), “407 Proxy Authentication required” (プロキシ認証が必要), “408 Request Timeout” (要求がタイムアウト), “410 Gone” (要求資源は利用不能になった), “413 Request Entity Too Large” (要求エンティティはサーバ能力をこえる), “414 Request-URI Too Long” (要求 URI は過長), “415 Unsupported Media Type” (メディアタイプ利用不能), “416 Unsupported URI Scheme” (サポートされない URI 形式), “420 Bad Extension” (サーバが理解できないプロトコル拡張), “421 Extension Required” (UAS にプロトコル拡張が必要), “423 Interval Too Brief” (資源の使用期限がみじかすぎる), “480 Temporarily Unavailable” (一時的な利用不可), “481 Call/Transaction Does Not Exist” (既存セッションのなかにない), “482 Loop Detected” (ループを検出), “483 Too Many Hops” (ホップ数過大), “484 Address Incomplete” (要求 URI が不完全), “485 Ambiguous” (要求 URI があいまい), “486 Busy Here” (呼び出し先が buzy), “487 Request Terminated” (要求は BYE / CANCEL により終了させられた), “488 Not Acceptable Here” (状況依存の受理不能), “491 Request Pending” (要求は保留されている), “493 Undecipherable” (処理不能な暗号)．

401 Unauthorized メッセージの例を前記の draft-ietf-sipping-basic-call-flows-02 から引用する．

   SIP/2.0 401 Unauthorized 
   Via: SIP/2.0/TLS 
client.biloxi.example.com:5061;branch=z9hG4bKnashds7 
    ;received=192.0.2.201 
   From: Bob ;tag=a73kszlfl 
   To: Bob ;tag=1410948204 
   Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com 
   CSeq: 1 REGISTER 
   WWW-Authenticate: Digest realm="atlanta.example.com", qop="auth", 
    nonce="ea9c8e88df84f1cec4341ae6cbe5a359", 
    opaque="", stale=FALSE, algorithm=MD5 
   Content-Length: 0 

(5) サーバ・エラー (5xx)

500 番台の応答メッセージはサーバにおいてエラーが発生したことをあらわすサーバ・エラー・メッセージである． サーバ・エラー・メッセージとしてはつぎのものが前記の RFC 3261 において定義されている: “500 Server Internal Error”, “501 Not Implemented”, “502 Bad Gateway”, “503 Service Unavailable”, “504 Server Time-out”, “505 Version Not Supported”, “513 Message Too Large”．

(6) 大域エラー (6xx)

600 番台の応答メッセージは大域的なエラーが発生したことをあらわす大域エラー・メッセージである． 大域エラー・メッセージとしてはつぎのものが前記の RFC 3261 において定義されている: “600 Busy Everywhere”, “603 Decline”, “604 Does Not Exist Anywhere”, “606 Not Acceptable”．

6. SIP における標準的なシーケンス

図6.1 のシーケンスは前記のインターネット・ドラフト draft-ietf-sipping-basic-call-flows-02 から引用した，SIP サーバを経由しない (またはそれが省略された) Alice と Bob との会話の標準的なシーケンスである．

   Alice                     Bob 
     |                        | 
     |       INVITE F1        | 
     |----------------------->| 
     |    180 Ringing F2      | 
     |<-----------------------| 
     |                        | 
     |       200 OK F3        | 
     |<-----------------------| 
     |         ACK F4         | 
     |----------------------->| 
     |   Both Way RTP Media   | 
     |<======================>| 
     |                        | 
     |         BYE F5         | 
     |<-----------------------| 
     |       200 OK F6        | 
     |----------------------->| 
     |                        | 

Alice が最初に送信している INVITE メッセージの内容は ??? 節に例示した INVITE メッセージのとおりであり，それに対する 200 OK メッセージの内容は前節に例示した 200 OK メッセージのとおりである． また，ACK メッセージと BYE メッセージの内容も前節に例示したとおりである． Alice が ACK メッセージを送信したあと，Bob から BYE メッセージを受信するまで RTP メディアによる双方向の通信がつづいている (上図の “Both Way RTP Media”)． SIP サーバを経由するシーケンスの例を 図 6.2 にあげる (前記の RFC 3261 から引用した)． ここでは atlanta.com と biloxi.com にある 2 個の SIP プロキシを経由して Alice と Bob とのあいだでメッセージが交換されている． これらのプロキシが INVITE メッセージを受信した直後に 100 Trying 応答をかえしていることを除けば，これらのプロキシはメッセージを中継しているだけである．

                     atlanta.com  ...biloxi.com
                 .     proxy              proxy     .
               .                                      .
       Alice's  .................... Bob's
      softphone                                        SIP Phone
         |                |                |                |
         |    INVITE F1   |                |                |
         |--------------->|    INVITE F2   |                |
         |  100 Trying F3 |--------------->|    INVITE F4   |
         |<---------------|  100 Trying F5 |--------------->|
         |                |<-------------- | 180 Ringing F6 |
         |                | 180 Ringing F7 |<---------------|
         | 180 Ringing F8 |<---------------|     200 OK F9  |
         |<---------------|    200 OK F10  |<---------------|
         |    200 OK F11  |<---------------|                |
         |<---------------|                |                |
         |                       ACK F12                    |
         |------------------------------------------------->|
         |                   Media Session                  |
         |<================================================>|
         |                       BYE F13                    |
         |<-------------------------------------------------|
         |                     200 OK F14                   |
         |------------------------------------------------->|
         |                                                  |

7. SIP サーバの役割

ユーザエージェントどうしは直接 SIP のメッセージを交換することができるが，通常は SIP サーバ (SIP プロキシサーバ) を介してメッセージ交換する． これは，直接通信するためには相手の IP アドレスがわかっていなければならないのに対して，SIP プロキシサーバを介することによって SIP URI から IP アドレスをもとめる操作をユーザエージェントがおこなう必要がなくなり，通信相手が移動するなどして IP アドレスが変化してもそれを意識せずに通信することができるからである．

8. SIP サーバの標準的な構成

SIP サーバはこの機能を実現するために，通常，つぎの 3 種類のサーバのくみあわせで実現される．

(1) SIP プロキシサーバ (SIP Proxy Server)

SIP メッセージの転送 (ルーティング) をおこなうサーバである． SIP ヘッダにふくまれる受信先アドレスをキーとして場所サーバへのといあわせをおこなって受信先の IP アドレスをもとめ，それにもとづいてメッセージの転送先を決定する． 転送先は受信先の IP アドレスであるか，または他のプロキシ・サーバである． このメッセージ・ルーティングの方法は SMTP によるメールのルーティングとおなじである． このルーティングの際には他のドメインにおける SIP サーバを発見するために DNS (Domain Name Server) が使用されるが，そのための方法は RFC 3263 (J. Rosenberg, H. Schulzrinne: Session Initiation Protocol (SIP): Locating SIP Servers) に記述されている．

(2) レジストラ (Registrar)

ユーザエージェントからのメッセージにもとづいてその SIP URI と IP アドレスの対を場所サーバに登録するサーバである． ユーザエージェントがネットワークに接続されると，ある間隔で REGISTER メッセージを送出する． REGISTER メッセージは SIP プロキシサーバ経由でレジストラにおくられ，これにもとづいてレジストラが上記の登録をおこなう． すなわち，レジストラへの入力は SIP メッセージ (REGISTER) である．

(3) 場所サーバ (Location Server)

場所サーバはユーザエージェントが存在するネットワーク上の場所を管理するデータベース管理サーバである． SIP URI と IP アドレスの対をレジストラからうけとって登録し，登録情報にもとづいて SIP プロキシサーバからのといあわせに返答する． 場所サーバの入出力は SIP メッセージではない．

通信相手が移動するなどして，これまで使用してきた SIP プロキシサーバを使用しつづけることが適当でないような場合には，メッセージ送付元に対して送付先を変更するようにリダイレクション・メッセージをかえすことができる． このようなリダイレクションの機能をもつサーバを SIP リダイレクトサーバ (Redirect Server) とよぶ．

9. SIP におけるトランザクションと対話の概念

SIP は基本的に要求応答型のプロトコルであるから，要求が生成されてからその応答が処理されるまでの処理をトランザクションという． サーバにおけるトランザクションをサーバ・トランザクションといい，これはサーバが要求をうけてからその応答をかえすまでのサーバの処理をさす． また，クライアントにおけるトランザクションをクライアント・トランザクションといい，これはクライアントが要求を生成してからその応答がかえるまでのクライアントの処理をさす． また，SIP においては通常 INVITE メッセージによって “セッション” が開始され，BYE メッセージによって “セッション” が終了する． この “セッション” のことを SIP の用語では対話 (dialog) とよぶ． 対話はセッション管理機能によって管理されるべきものそのものであるからセッション管理機能にとって重要だが，トランザクションは対話の構成要素として重要である． これらの概念はつぎの API に反映されている．

10. SIP API の例

SIP そのものの実装すなわちプロトコル・スタックには，商用のものからフリーのものまで，様々なものがある． そのなかに公開された SIP API もいくつかあるが，Java によって記述された 3 つの API についてだけ調査をおこなった．

(1) JAIN SIP

JAIN (Java APIs for Integrated Networks) は Sun Microsystems 社が中心となって開発されている， Java による一連のネットワーク API の総称である． JAIN の名のもとに API 仕様が公開され，各社がそれにもとづくプログラムを開発している． SIP に関しても，そのプロトコルを実現する基本の API が JAIN SIP として規定されている． また，関連する JAIN の API として高水準かつ軽量の SIP である SIP Lite, SIP を使用するサーバの部品開発のための SIP Servlet, モバイルデバイスくみこみのための SIP J2ME などがある． SIP Servlet は J2EE (Java2 Enterprise Edition すなわちサーバ版 Java) 上，SIP J2ME は J2ME (Java2 Micro Edition すなわちくみこみ版 Java) 上で動作するが，他は J2SE (Java2 Standard Edition すなわち標準版 Java) 上で動作する． JAIN SIP の参照実装 (reference implementation) が dynamicsoft 社から無償で提供されているが，これは最低限の機能を実装したものであり，dynamicsoft 社は有償のプログラムも販売している．

(2) NIST SIP

米国の国立機関である NIST (National Institute of Standards and Technology) において開発された SIP スタックであり (Project: Internet Telephony / VOIP, http://www-x.antd.nist.gov/proj/iptel/)，JAIN SIP の仕様に準拠している． この SIP スタックを使用した SIP プロキシなどのアプリケーション・プログラムもあわせて提供されている． NIST の開発物は米国の法律によって著作権を主張しないことがきめられているため，NIST SIP も著作権フリーであり，自由に改造して使用することができる． NIST SIP は技術実験のクライアントにおいて使用している．

(3) Siptrex

英国の大学である UCL (University College London) において，数人の学生プロジェクトによって SIP スタックおよび一連のアプリケーションが開発され，siptrex.com の名のもとに公開されている． この SIP スタックは NIST SIP の旧版にもとづいているが，プログラムはほとんどかきかえられているようである． アプリケーションとしては SIP プロキシ，レジストラ，場所サーバ (これらについては第 3 章参照)，クライアントが提供され，これらをくみあわせて使用することによって，Siptrex だけで IP 電話の実験をおこなうことができる． 使用にあたっては事前に連絡することが義務づけられている． 使用条件は明文化されていないが，これ以上の条件はつけられていない．

なお，これらのほかに米国 Columbia 大学で開発された Java SIP ライブラリ CU-JSIP がある (http://www1.cs.colum-bia.edu/~pallavi/research/index.html) が，Web サイトではプログラムは公開されていない．

11. JAIN SIP API

前節において述べた API のなかで JAIN SIP API についてさらに詳細に検討する． 2003 年 6 月に公開された JAIN SIP API 1.1 の仕様は “JAIN-SIP API Specification Version 1.1” (http://jcp.org/aboutJava/communityprocess/final/jsr032/index2.html) によって与えられている．- JAIN SIP においては SipProvider と SipListener という 2 個のインタフェースがもっとも重要だと考えられる． ここでインタフェース (interface) というのは Java 固有の概念であり，メソッドや例外の仕様を束ねたものである． あるクラスがあるインタフェースを実装するというとき，そのクラスはこれらのメソッドや例外を実装しなければならない． たとえば SipListener にはつぎの 3 個のメソッドが定義されている．

public void processRequest(RequestEvent requestEvent)，
public void processResponse(ResponseEvent responseEvent)，
public void processTimeout(TimeoutEvent timeoutEvent).

したがって，SipListener を実装するクラスはこれらのメソッドを実装する必要がある．

JAIN SIP における SIP を使用するアプリケーション (ユーザエージェント，SIP プロキシなど) の核の部分は 図 11.1 のような構造をしている．

                                メッセージ送信
                         (sendRequest(), sendResponse())
                                 イベント登録
                               (addSipListener())
  アプリ        SIP    ---------------------------------->   SIP         SIP
ケーション -- Listener <---------------------------------- Provider -- スタック
                         イベント発生 (メッセージ受信等)
             (processRequest(), processResponse(), processTimeout())

すなわち，SIP による通信は SipProvider を実装したオブジェクト (SIP Provider とよぶ) がおこなうが，それを使用するクラスは SipListener インタフェースを実装し，そのクラスのオブジェクト (SIP Listener とよぶ) は SIP の使用前に addSipListener メソッドを使用してイベント発生を受理することを SIP Provider に伝える． 他のアプリケーションに SIP メッセージを送信するときは SIP Provider のメソッドを呼び出す．すなわち，それが要求メッセージであれば sendRequest メソッド，応答メッセージであれば sendResponse メソッドを呼び出す． また，他のアプリケーションから SIP メッセージが SIP Provider にとどくと，SIP Listener にイベントを発生される． すなわち，それが要求メッセージであれば processRequest メソッド，応答メッセージであれば processResponse メソッドが呼び出される．

JAIN SIP API はつぎの 4 個のパッケージによって構成されている．

(1) javax.sip

SIP スタックと，アプリケーションを構築するのに必要な SipListener, SipProvider などのインタフェースや SipFactory クラスを含んでいる．

(2) javax.sip.address

SIP プロトコルにおける URI などのアドレス要素を含んでいる． 具体的には，Address, AddressFactory, Hop, Router, SipURI, TelURL, URI という 7 個のインタフェースを含んでいる．

(3) javax.sip.header

SIP の各種のメッセージ・ヘッダを表現するインタフェースを含んでいる． そのなかには，たとえば CSeqHeader, FromHeader, ToHeader などのインタフェースがある．

(4) javax.sip.message

Message, Request, Response という 3 個の SIP のメッセージを表現するインタフェースと，それらのインスタンスを生成するための MessageFactory クラスとを含んでいる．

12. JAIN SIP における jaavax.sip パッケージ

前節において述べた JAIN SIP のパッケージのなかでとくに重要な javax.sip についてさらに記述する． javax.sip は 7 個のクラス，8 個のインタフェース，8 個の例外によって構成されている．JAIN SIP に対しては複数の異なる実装を与えることができるが，これらのインタフェースのうち Listening-Point, Parameters, Sip-Provider, Sip-Stack に対しては，個々の実装においてそれぞれを実装するクラス Listening-Point-Impl, ParametersImpl, Sip-Provider-Impl, Sip-Stack-Impl を与える． たとえば，NIST SIP においてはパッケージ gov.nist.javax.sip においてこれらのクラスが実装されている． javax.sip に属する 8 個のインタフェースは次のとおりである．

(1) Sip-Listener

すでにのべたように，SIP を使用するクラスが実装するべきインタフェースであり，つぎの 3 個のメソッドを持っている:

public void processRequest(RequestEvent requestEvent)
	SIP 要求メッセージを受信したことを通知する．
public void processResponse(ResponseEvent responseEvent)
	SIP 応答メッセージを受信したことを通知する．
public void processTimeout(TimeoutEvent timeoutEvent)
	タイムアウトを通知する．

これらのメソッドのなかで process-Request はサーバが実行するものであり，process-Response はクライアントが実行するものである． したがって，JAIN SIP においてはサーバとクライアントとがひとつのインタフェースに混在している． これに対して SIP J2ME においてはこれらが分離され，UAS のインタフェースとして Sip-Client-Connection-Listener，UAC のインタフェースとして Sip-Server-Connection-Listener が定義されている． このようにサーバとクライアントとを分離することでインタフェースの数が増加するが，IETF の SIP のモデルとの整合性はよくなると考えられる． また，タイムアウトの処理法として，JAIN SIP においては上記のように processTimeout というメソッドが使用されるが，SIP J2ME においてはメッセージ受信のためのメソッドの引数としてタイムアウトを指定するようになっている． タイムアウト時間として 0 を指定するとすでにメッセージが到着しているときにかぎってうけとることを意味する． この API のほうがプログラマにとって直観的に理解しやすいと考えられる．

(2) Listening-Point

リスニングポイントは SIP メッセージ受信用のポート，トランスポート・プロトコル (UDP または TCP) などを含むオブジェクトであり，そのクラスが ListeningPoint である．つぎのメソッドを持っている．

boolean equals(java.lang.Object obj)
	引数 (obj) がこの ListeningPoint とひとしいときは真，そうでないときは偽．
int getPort()
	ポートをもとめる．
java.lang.String getTransport()
	トランスポート・プロトコルをもとめる．

(3) SipProvider

SIP の機能を提供するクラス (ライブラリの一部) が実装するべきインタフェースであり，つぎのメソッドを持っている．

void addSipListener(SipListener sipListener)
	sipListener が SIP イベントを受けるようにする．
	(sipListener は SipListener インタフェースを実装している必要がある．)
ListeningPoint getListeningPoint()
	登録されたリスニングポイント (ListeningPoint) をもとめる． 
CallIdHeader getNewCallId()
	新しい (一意性が保証された) Call ID をもとめる． 
ClientTransaction getNewClientTransaction(Request request)
	新しいクライアント・トランザクション ( 5) を参照) を生成する． 
ServerTransaction getNewServerTransaction(Request request)
	新しいサーバ・トランザクション ( 6) を参照) を生成する． 
SipStack getSipStack()
	この SIP Provider に関連づけられた SIP スタックをもとめる． 
void removeSipListener(SipListener sipListener)
	sipListener が SIP イベントの受信をやめる． 
void sendRequest(Request request)
	SIP 要求メッセージを送信する． 
void sendResponse(Response response)
	SIP 応答メッセージを送信する． 
void setListeningPoint(ListeningPoint listeningPoint)
	SIP メッセージ受信用のリスニングポイント (ListeningPoint) を登録する． 

ここでもクライアントにおいて使用するメソッド get-New-ClientTransaction，send-Request と，サーバにおいて使用するメソッド get-NewServer-Transaction，send-Response とがひとつのクラスのなかに共存している． これらも SIP J2ME においては分離されている．

(4) SipStack

SIP のプロトコルスタックを表現するクラスである． つぎのメソッドを持っている．

ListeningPoint createListeningPoint(
                      int port, java.lang.String transport)
	このスタックに関係づけられたリスニングポイントを生成する．
SipProvider createSipProvider(ListeningPoint listeningPoint)
	このスタックに関係づけられた SipProvider を生成する．
void deleteListeningPoint(ListeningPoint listeningPoint)
	このスタックに関係づけられたリスニングポイントを抹消する．
void deleteSipProvider(SipProvider sipProvider)
	このスタックに関係づけられた SipProvider を抹消する． 
java.lang.String getIPAddress()
	このスタックの IP アドレスをもとめる．
java.util.Iterator getListeningPoints()
	このスタックに関係づけられたリスニングポイントをもとめる． 
Router getRouter()
	このスタックのメッセージ・ルータをもとめる． 
java.util.Iterator getSipProviders()
	 このスタックに関係づけられた SipProvider をくりかえしごとに 1 個ずつかえす． 
java.lang.String getStackName()
	 このスタックの名称をもとめる． 
boolean isRetransmissionFilterActive()
	 再送フィルタがアクティブなら真 (true)，そうでなければ偽 (false) をかえす． 

(5) Transaction

トランザクションを表現するインタフェースであり，このインタフェースを実装するクラスとして次に述べる ClientTransaction, ServerTransaction がある． つぎのメソッドを持っている．

java.lang.String getBranchId() 
	トランザクションを識別する ID をかえす． 
Dialog getDialog() 
	そのトランザクションをふくむ対話をかえす． 
Request getRequest() 
	そのトランザクションを開始した要求の内容をかえす． 
int getRetransmitTimer() 
	再送タイマの値をかえす． 
TransactionState getState() 
	そのトランザクションの状態をかえす． 
void setRetransmitTimer(int retransmitTimer) 
	再送タイマの値をセットする． 

(6) ClientTransaction

クライアントにおける一連のメッセージ (トランザクション) を表現するクラスである． つぎの 3 個のメソッドを持っている:

Request createAck()
	 ACK を生成する．(INVITE によって開始されたトランザクションのとき.)
Request createCancel()
	 CANCEL (メッセージ) を生成する． 
void sendRequest()
	 トランザクションを開始するためのメッセージを送信する． 

(7) ServerTransaction

サーバにおける一連のメッセージ (トランザクション) を表現するクラスである． サーバ・トランザクションはクライアントから要求メッセージを受信することによって開始されるので，ServerTransaction クラスのオブジェクトはつぎのように要求メッセージを指定して生成される．

new serverTransaction(request)

ServerTransaction はつぎの 1 個のメソッドを持っている:

sendResponse(Response response)
	 応答メッセージを送信する． 

(8) Dialog

2 個のユーザエージェント間の会話を表現するクラスである． アプリケーションはこのクラスのオブジェクトを陽にあつかわないが，トランザクション (Transaction) においてあたらしい会話が自動的に生成されるかまたは既存の会話が検索されてトランザクションと関連づけられ，INVITE, BYE などのメッセージの送信によって状態遷移する． Dialog クラスのオブジェクトの状態をあらわすためのクラスが，次項の DialogStatus である． Dialog はつぎのメソッドを持っている．

Request createRequest(java.lang.String method)
	その対話の情報にもとづいて，指定されたメソッドの新しい要求をつくる． 
void delete()
	その対話にわりあてられた資源を開放する． 
java.lang.Object getApplicationData()
	その対話のアプリケーション依存のデータをもとめる． 
CallIdHeader getCallId()
	その対話に対応する SIP の Call ID をかえす． 
java.lang.String getDialogId() 
	その対話の対話 ID をかえす (対話 ID は SIP 上にはあらわれない)． 
Transaction getFirstTransaction() 
	その対話を開始したトランザクションをもとめる． 
Address getLocalParty() 
	自分 (対話の一方の局) のアドレスをもとめる． 
int getLocalSequenceNumber() 
	自分のシーケンス番号をもとめる． 
java.lang.String getLocalTag() 
	自分のタグ (From ヘッダまたは To ヘッダにつけるタグ) をもとめる． 
Address getRemoteParty() 
	相手 (対話の他方の局) のアドレスをもとめる． 
int getRemoteSequenceNumber() 
	相手のシーケンス番号をもとめる． 
java.lang.String getRemoteTag() 
	相手のタグをもとめる． 
Address getRemoteTarget() 
	リモート・ターゲットのアドレスをもとめる． 
java.util.Iterator getRouteSet() 
	Record-Route ヘッダによって指定された経路をもとめる． 
DialogState getState() 
	対話の状態をもとめる． 
void incrementLocalSequenceNumber() 
	自分のシーケンス番号を 1 ふやす． 
boolean isSecure() 
	TLS を使用するセキュアな対話であるかどうかを判定する． 
boolean isServer() 
	対話において自分がサーバとしてはたらいているかどうかを判定する． 
void sendAck(Request ackRequest) 
	ACK を送信する． 
void sendRequest(ClientTransaction clientTransaction) 
	指定されたクライアント・トランザクションの要求を送信する． 
void setApplicationData(java.lang.Object applicationData) 
	アプリケーション依存のデータをセットする． 

また，javax.sip に属する 7 個のクラスは次のとおりである．

(9) RequestEvent

要求メッセージの到着を表現するイベントである． つぎのメソッドを持っている．

Request getRequest()
	 イベント発生の原因となった要求メッセージをもとめる． 
ServerTransaction getServerTransaction()
	 上記の要求メッセージによって開始されたトランザクションをもとめる． 

(10) ResponseEvent

応答メッセージの到着を表現するイベントである． つぎのメソッドを持っている．

ClientTransaction getClientTransaction() 
	その応答に対応するクライアント・トランザクションをもとめる． 
Response getResponse()
	その応答をもとめる． 

(11) DialogState

会話 (Dialog クラスのオブジェクト) がとる 4 個の状態 Early, Confirmed, Completed, Terminated のうちのいずれかをあらわす． つぎのメソッドを持っている．

static DialogState getObject(int dialogState) 
	指定された (状態をあらわす) 整数値から状態の値をもとめる． 
int getValue() 
	その状態に対応する整数値をもとめる． 
java.lang.String toString()
	その状態の文字列表現をもとめる． 

ここで getObject() はクラス・メソッドであるから，DialogState.getObject(dialogState) のように使用する．

(12) SipFactory

AddressFactory, HeaderFactory, MessageFactory などのインタフェースを実装したクラスのインスタンスを生成するメソッドを備え，SIP スタックを初期化するための機能などを備えている． 具体的には，つぎのメソッドを持っている．

AddressFactory createAddressFactory() 
	AddressFactory を実装するクラスのインスタンスを生成する． 
HeaderFactory createHeaderFactory() 
	HeaderFactory を実装するクラスのインスタンスを生成する． 
MessageFactory createMessageFactory() 
	MessageFactory を実装するクラスのインスタンスを生成する． 
SipStack createSipStack() 
	SipStack (SIP スタック) を実装するクラスのインスタンスを生成する． 
static SipFactory getInstance() 
	SipFactory のインスタンスを生成する． 
java.lang.String getPathName() 
	setPathName によって指定された SIP の実装を含むパスを得る． 
void resetFactory()
	SipFactory を初期状態に戻す． 
void setPathName(java.lang.String pathName)  
	特定の SIP 実装 (SipProvider, SipFactory などの実装) を含むパスを指定する． 

(13) Timeout

タイムアウトが発生した状況を示すクラスである． つぎのいずれかの値をとる: RETRANSMIT, TRANSACTION．つぎのメソッドを持っている．

Timeout getObject(int timeout) 
	指定されたタイムアウト時間をもつ Timeout オブジェクトをもとめる． 
int getValue() 
	その Timeout オブジェクトがあらわすタイムアウト時間をもとめる． 
java.lang.String toString()
	文字列に変換する． 

(14) TimeoutEvent

SIP 通信におけるタイムアウトによって発生するイベントを表現するクラスである． つぎのメソッドを持っている．

ClientTransaction getClientTransaction() 
	このイベントに関係づけられたクライアント・トランザクションを得る． 
ServerTransaction getServerTransaction() 
	このイベントに関係づけられたサーバ・トランザクションを得る． 
Timeout getTimeout() 
	このイベントのイベント型を得る． 
boolean isServerTransaction()
	このイベントがサーバ・トランザクションに関連づけられているかどうか． 

(15) TransactionState

トランザクションの状態を表現するクラスである． 状態は Calling, Trying, Proceeding, Completed, Confirmed, Terminated の 6 状態のうちのいずれかである． つぎのメソッドを持っている．

static TransactionState getObject(int transactionState)
	指定された整数値に対応するトランザクション状態をもとめる． 
int getValue() 
	そのトランザクション状態に対応する整数値をもとめる． 
java.lang.String toString()
	文字列に変換する． 

13. Cisco SIP Proxy Server

Cisco SIP Proxy Server (CSPS) は Cisco 社が開発した SIP サーバである． 以下ではおもに Cisco SIP Proxy Server Administrator Guide Version 2.1 (2003 年 9 月に WWW 上で公開) および Version 2.0 からの調査結果を，認証機能に重点をおいて記述する．

(1) 基本機能

CSPS Version 2.1 は SIP の新標準 RFC 3261 および旧標準RFC 2543 に準拠した SIP サーバである (CSPS Version 2.0 は RFC 2543 だけに準拠していた)． 名称は Proxy Server となっているが，SIP プロキシサーバとしてだけでなく，設定により SIP リダイレクトサーバまたはレジストラとして機能させることもできる． CSPS はおもにつぎの 4 個の要素によって構成されている．

• SIP Proxy Server (sipd): SIP サーバ本体である．
• Provisioning Server (pserver): SIP Proxy Server の構成などを Provisioning GUI client を通じて設定するためのサーバである．
• MySQL: 設定情報やユーザ情報などを格納するためのデータベース管理システム (DBMS) である． CSPS において使用可能な DBMS は MySQL だけである．
• Provisioning GUI client: SIP Proxy Server の構成などを Provisioning Server を通じて設定するためのクライアントである． このクライアントを使用することによって，SIP サーバの基本的な設定や後述するサーバファームの設定などをメニューにもとづいておこなうことができるが，MySQL をはじめとするそれ以外の設定のためには CLI (コマンドライン・インタフェース) に頼らざるをえない．

SIP を使用して会話などをおこなうユーザに関する情報を格納するため，上記のMySQL データベースか RADIUS サーバが使用される． ここで RADIUS (Remote Authentication Dialin User Service) とは IETF のドキュメント RFC 2138 (C. Rigney, A. Rubens, W. Simpson, S. Willens: Remote Authentication Dial In User Service (RADIUS)) および RFC 2139 (C. Rigney: RADIUS Accounting) によって標準化されたユーザ認証と認可，課金のためのプロトコルである． RADIUS はもともとはその名のとおりダイアルアップ接続における認証のために開発されたが，現在では VPN や無線 LAN など，様々なネットワークサービスにおいて使用されている． 上記の要素のほかに，CSPS の起動・停止やモニタリングなどの目的のために CIAgent とよばれる SNMP エージェントが使用される． SNMP (Simple Network Management Protocol) は IETF において標準化されたネットワーク管理のためのプロトコルであり，SNMP エージェントは管理対象の機器上に存在して，通常はその外部にある SNMP マネジャからおくられる SNMP による設定やといあわせにこたえるプログラムのことをいう．

(2) 認証機能

CSPS において可能な認証の方法は CHAP パスワード認証，HTTP ダイジェスト認証，HTTP 基本認証の 3 種類であり，既定の方法は HTTP ダイジェスト認証である． HTTP ダイジェスト認証または HTTP 基本認証がつかわれるときは，認証ヘッダまたはプロキシ認証ヘッダにあるユーザ名をキーとして MySQL データベースが検索される． CHAP 認証がつかわれるときは，ユーザ名が〈属性, 値〉の対のひとつとして CSPS からRADIUS サーバにわたされる． また，のぞみの SIP ヘッダをあわせて RADIUS サーバにおくるように CSPS を設定することができる． ユーザ名にドメイン名をつけて検索するようにすることもできる． CSPS においてアクセス制御リストとユーザ認証とを使用できるので，これらをくみあわせることによってより複雑なアクセス制御をおこなうことができる． 他のデバイスからの REGISTER メッセージや INVITE メッセージは CSPS によってユーザ認証要求する (challenge) ように設定することができる．

(3) 認可機能

CSPS においては認証されたユーザはただちに認可される． すなわち，現在のところユーザごとの認可機能は存在しない． しかし，IP アドレスによる認可機能はそなえている． その指定形式は Apache Web サーバによく似ている． ただし，Version 2.0 以降は認可に関する記述を設定ファイルに直接記述する方法のほかに GUI を使用して設定する方法があらたにサポートされた (Version 2.0 の Administration Guide によれば，GUI を使用する場合は設定ファイルを編集しても無効である)．

(4) サーバファーム機能

複数の CSPS からなるグループがデータベース情報を共有するように設定することができる． これによって CSPS によるサーバファームを構成することができ，冗長性と高可用性を実現することができる． サーバファームのメンバーが指定されると，メンバーごとにデータベースのレプリカがつくられる．

(5) セキュリティ機能

認証および認可に関する機能は上記のとおりである． RFC 3261 に準拠しているということは，トランスポート・プロトコルとして UDP, TCP だけでなく (TCP 上の) TLS を使用することができるということを意味している (??? 節参照) が，Version 2.1 の Administrator Guide には，実際，TLS に関する設定や仕様について記述されている．