調査と解説

1. 概要

SIP においては，通常，SIP URI と IP アドレスとの対がデータベースに保管される．このデータベースを検索することによって，メッセージに宛先などに指定されたユーザの SIP アドレスからそのユーザの端末の IP アドレスなどを求めることができる．データベースは通常，ドメイン単位で管理される．従って，検索の際にはまずそれを管理する SIP サーバを発見することが必要であり，そのためには DNS が使用される．

また，プレゼンスに関する SIP 拡張 (SIMPLE) を使用することによって，IP アドレスだけでなく，ユーザのプレゼンスつまりネットワーク上でアクセスできるかどうか，あるいは会話可能な状態にあるかどうかなどの情報をあわせて管理することができる．

通常，SIP URI から IP アドレスをもとめる検索は通信相手を呼び出す際，すなわち INVITE メッセージを送信する際に要求駆動で実行される．しかし，プレゼンスなどの情報はそれ以前に，すなわち事前にイベント駆動で伝播される．

2. 要求駆動の検索

SIP においては，ユーザエージェントがネットワークに接続されたときなどに REGISTER メッセージを発行する．このメッセージが SIP プロキシなどを経由してレジストラにとどくと，SIP URI と IP アドレスとの対が場所サーバのデータベースに登録される．そして，ユーザエージェントが INVITE メッセージを発行した際には SIP プロキシがレジストラに (要求駆動で) 問い合わせることによってメッセージ送信先の SIP URI から IP アドレスをもとめて，それをもとにしてメッセージの転送先を決める． 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 

SIP プロキシは，REGISTER メッセージの先頭行において指定された登録先 (この例においては sips:ss2.biloxi.example.com) が SIP プロキシと同一ドメイン内にあればそれに登録するが，ドメインがことなるときは DNS を使用し，NAPTR，SRV などの RR を使用して登録先を発見する．このような SIP サーバの発見の方法については RFC 3263 (J. Rosenberg, H. Schulzrinne: Session Initiation Protocol (SIP): Locating SIP Servers) において記述されている．

また，INVITE メッセージなどの転送においても，SIP プロキシは検索するべき URI がそのプロキシが属するドメインのものであればそのドメインのレジストラに問い合わせるが，それが他のドメインのものでればまずそのドメインのレジストラを発見する必要がある．このときも RFC 3263 に記述された方法を使用する (なお，SIP サーバの発見はメッセージのルーティングにおいても必要である)．

通常は特定の相手 (ユーザエージェント) を 1 個のレジストラに対してだけ問い合わせる．しかし，複数のレジストラに並行して問い合わせる，つまり並行検索を行うこともできる．

また，SIP URI を特定の相手と解釈するかわりに特定のサービスを表現するものだと解釈することもできるので，特定の相手を検索するかわりに特定のサービスを検索することもできる．ただし，SIP においては名前からの検索しかできず属性からの検索はできないので，サービス属性を指定して条件をみたすサービスを検索することはできない．

ただし，SIP メッセージの本体においてメディア通信に使用するプロトコルやコーデックなどを SDP (Session Description Protocol) を使用して記述することはできるので，SIP サーバの機能を拡張することによって (現在の標準からははずれるが) サービス属性にもとづく検索を行うことは可能である．

3. イベント駆動の発見

前節において述べたように，SIP における通常の方法においては，レジストラに登録された情報は要求駆動で検索する．しかし，これでは登録内容が変更されてもただちに把握することができず，移動したユーザエージェントに対して通信を継続することができないというような状況が生じうる．そこで，2002 年 10 月に発行されたインターネット・ドラフト draft-ietf-sipping-reg-event-00 (J. Rosenberg: A Session Initiation Protocol (SIP) Event Package for Registrations) において，登録内容の変更をイベント駆動で発見する機構が提案された．

この提案における方法においては，登録内容変更によって発生するイベントを受理したいアプリケーションはイベント名 reg を指定してレジストラに対して SUBSCRIBE 要求を送信する．すると，レジストラは REGISTER メッセージが届くたびにイベントを通知する．すなわち，イベント名 reg を指定した NOTIFY 要求をアプリケーションに対して送信する．前記のインターネット・ドラフト draft-ietf-sipping-reg-event-00 から例を引用する．まず，シーケンス図は 図 1 のとおりである．

        User              Registrar          Application
          |                   |(1) SUBSCRIBE      |
          |                   |Event:reg          |
          |                   |<------------------|
          |                   |(2) 200 OK         |
          |                   |------------------>|
          |                   |(3) NOTIFY         |
          |                   |------------------>|
          |                   |(4) 200 OK         |
          |                   |<------------------|
          |(5) REGISTER       |                   |
          |------------------>|                   |
          |(6) 200 OK         |                   |
          |<------------------|                   |
          |                   |(7) NOTIFY         |
          |                   |------------------>|
          |                   |(8) 200 OK         |
          |                   |<------------------|
          |(9) MESSAGE        |                   |
          |<--------------------------------------|

この例においては，まずアプリケーションが SUBSCRIBE 要求をレジストラに送信してその応答を受け，つぎにレジストラが現状の登録内容を NOTIFY 要求によってアプリケーションに送信する．その後，レジストラにユーザ (ユーザエージェント) から REGISTER メッセージがとどき，それに関する通知をアプリケーションに対して NOTIFY 要求によって送信している．その結果を受けて，アプリケーションはユーザに対してメッセージを送信している．このシーケンスにおける (1) のメッセージの内容は次のとおりである．

   SUBSCRIBE sip:joe@bar.com SIP/2.0
   Via: SIP/2.0/UDP app.bar.com;branch=z9hG4bKnashds7
   From: sip:app.bar.com;tag=123aa9
   To: sip:joe@bar.com
   Call-ID: 9987@app.bar.com
   CSeq: 9887 SUBSCRIBE
   Contact: sip:app.bar.com
   Event: reg
   Max-Forwards: 70
   Accept: application/reginfo+xml

また，(7) のメッセージの内容は次のとおりである．

   NOTIFY sip:app.bar.com SIP/2.0
   Via: SIP/2.0/UDP server19.bar.com;branch=z9hG4bKnasaij
   From: sip:joe@bar.com;tag=xyzygg
   To: sip:app.bar.com;tag=123aa9
   Call-ID: 9987@app.bar.com
   CSeq: 1289 NOTIFY
   Contact: sip:server19.bar.com
   Event: reg
   Max-Forwards: 70
   Content-Type: application/reginfo+xml
   Content-Length: ...

   <?xml version="1.0"?>
   <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
                version="1" state="partial">
     <registration aor="sip:joe@bar.com" id="a7" state="active">
       <contact id="76" state="active" event="registered"
            duration-registered="0">sip:joe@pc34.bar.com</contact>
     </registration>
   </reginfo>

ここでは登録内容が NOFITY メッセージの本体に XML の形式で記述されている．