読者です 読者をやめる 読者になる 読者になる

猫型エンジニアのブログ

プログラム/ネットワーク系の技術関連をまとめたページです 

SIPお勉強 その2

SIPを理解するのに一番確実なのは、RFCを見ながら実際にSIPスタックを実装することだと思う。時間があれば是非やってみたいけど、なかなか難しそう。とりあえずこことかに参考になりそうな資料がある。

いままでだましだましでSIP業務やってきたけど、RFCを真剣に読むのは初めて。意外に内容が読み取りにくくで、いろんな箇所に記述が分散しているので読みにくい...。

SIP用語その2

今回は各ヘッダの概要に関して。

Viaヘッダ

要はSIP信号がたどったパス(アドレス・ポート・トランスポートプロトコル)を示すと思えばだいたい正しい。パケットの送信元IPアドレスだけを通信に使えばよさそうだが、それでは経由する各ホップごとにポート番号やプロトコル(UDP/TCP/TLS)が異なることや、NAT変換の処理などが問題になると思う。IPレベルのL3で通信できることと、SIPのL7レベルで通信できることとは意味が異なる。

branchの値はトランザクションの識別のために用いられるのね。パラレルサーチ(その3参照)ではDialog-IDの完成前にはbranchでトランザクションを識別するのだろう。

  • UACがリクエストを生成するとき、それはそのリクエストにViaを挿入しなければならない。Viaヘッダーフィールド値はbranchパラメータを含まなければならない。
  • Viaヘッダーフィールドは、トランザクションのために使用されるトランスポートを示し、また応答が送られることになる場所を特定する。
  • Viaヘッダーフィールドは、これまでにリクエストがたどったパスと、応答を ルートするときにたどるべきパスを示す。Viaヘッダーフィールド値のbranchIDパラメータは、トランザクション識別子としての役に立ち、ループ検知のためにプロキシに利用される。
  • Viaヘッダーフィールド値は、メッセージを送るために使用されるトランスポートプロトコル、クライアントのホスト名またはネットワークアドレス、およびおそらくはそれが応答を受け取ることを望むポート番号を含む。(rfc3261)
Fromヘッダ

FromもToもタグに役割があるのは知らんかった。FromとToの両方のタグがついていないとダイアログとしては「未完成」という扱いらしい...。

Fromタグ/Toタグの両方が揃うには送受信両方の協力が必要。受信側の協力なしには発信側は一つのリクエストで確立される複数のダイアログを明確化することができない。

そもそも「リクエストのフォークとは、一つのリクエストから複数のダイアログが確立できることを意味する。」のようなケースではCall-IDだけだとダイアログの識別ができないのね。

  • Fromヘッダーフィールドは、リクエストを開始した者の論理的なアイデンティティを示す。これはおそらく、ユーザーのAddress-of-Recordであろう
  • FromタグはUAC側が発信時に生成する(ToタグはUAS側が生成する)。
Toヘッダ

Toヘッダが最終的な受信者とはかぎらないのね...。

  • Toヘッダーフィールドは、まず、希望するリクエストの「論理的」な受信者、 またはこのリクエストのターゲットであるユーザーあるいはリソースのAddress-of-Recordを指定する。これは、リクエストの最終的な受信者であるかもしれないし、そうでないかもしれない。
  • Toタグ:ダイアログが確立していないリクエストはToタグをふくんではならない。
Contactヘッダ

Fromヘッダ/Toヘッダと役割が被っているようで被っていない...。Contactヘッダではきちんと「FQDNIPアドレス)」と指定されている。

今後のリクエストを送信する場合の「送信先」を記述する。そのため「リクエスト」と「レスポンス」それぞれでContactヘッダの値は異なる。INVITEリクエストのみが含まれる。

  • Contactヘッダーフィールドは、これに続くリクエストでそのUAの特定のインスタンスにコンタクトするために使用できるSIP URIまたはSIPS URIを提供する。Contactヘッダーフィールドは、結果としてダイアログを確立することができるすべてのリクエストの中に、正確に一つのSIPまたはSIPS URIを含んで存在しなければならない。(rfc3261)
  • 通常は完全修飾ドメイン名(FQDN)におけるユーザー名からなるSIP URIまたはSIPS URIを含む。FQDNが望ましいとはいえ、多くのエンドシステムはドメイン名を登録していないので、IPアドレスが許可されている。Viaヘッダーフィールドが応答をどこに送るかを他のエレメントに伝えるのに対して、Contactヘッダーフィールドは、今後のリクエストをどこに送るかを他のエレメントに伝える。
Routeヘッダ

プロキシ関連のヘッダ

  • Routeヘッダーフィールドは、リストされたプロキシのセットを経由してリクエストをルーティングさせるために使用される。
Record-Routeヘッダ

プロキシ関連のヘッダ

  • Record-Routeヘッダーフィールドは、ダイアログ中のそれ以降のリクエストをプロキシを通してルートさせるために、そのプロキシによってリクエストに挿入される。