SIPお勉強 その２
SIPを理解するのに一番確実なのは、RFCを見ながら実際にSIPスタックを実装することだと思う。時間があれば是非やってみたいけど、なかなか難しそう。とりあえずこことかに参考になりそうな資料がある。
いままでだましだましでSIP業務やってきたけど、RFCを真剣に読むのは初めて。意外に内容が読み取りにくくで、いろんな箇所に記述が分散しているので読みにくい...。
SIP用語その２
今回は各ヘッダの概要に関して。
Viaヘッダ
要はSIP信号がたどったパス（アドレス・ポート・トランスポートプロトコル）を示すと思えばだいたい正しい。パケットの送信元IPアドレスだけを通信に使えばよさそうだが、それでは経由する各ホップごとにポート番号やプロトコル(UDP/TCP/TLS)が異なることや、NAT変換の処理などが問題になると思う。IPレベルのL３で通信できることと、SIPのL７レベルで通信できることとは意味が異なる。
branchの値はトランザクションの識別のために用いられるのね。パラレルサーチ（その３参照）ではDialog-IDの完成前にはbranchでトランザクションを識別するのだろう。
- UACがリクエストを生成するとき、それはそのリクエストにViaを挿入しなければならない。Viaヘッダーフィールド値はbranchパラメータを含まなければならない。
- Viaヘッダーフィールドは、トランザクションのために使用されるトランスポートを示し、また応答が送られることになる場所を特定する。
- Viaヘッダーフィールドは、これまでにリクエストがたどったパスと、応答を ルートするときにたどるべきパスを示す。Viaヘッダーフィールド値のbranchIDパラメータは、トランザクション識別子としての役に立ち、ループ検知のためにプロキシに利用される。
- Viaヘッダーフィールド値は、メッセージを送るために使用されるトランスポートプロトコル、クライアントのホスト名またはネットワークアドレス、およびおそらくはそれが応答を受け取ることを望むポート番号を含む。(rfc3261)
Fromヘッダ
FromもToもタグに役割があるのは知らんかった。FromとToの両方のタグがついていないとダイアログとしては「未完成」という扱いらしい...。
Fromタグ/Toタグの両方が揃うには送受信両方の協力が必要。受信側の協力なしには発信側は一つのリクエストで確立される複数のダイアログを明確化することができない。
そもそも「リクエストのフォークとは、一つのリクエストから複数のダイアログが確立できることを意味する。」のようなケースではCall-IDだけだとダイアログの識別ができないのね。
Toヘッダ
Toヘッダが最終的な受信者とはかぎらないのね...。
- Toヘッダーフィールドは、まず、希望するリクエストの「論理的」な受信者、 またはこのリクエストのターゲットであるユーザーあるいはリソースのAddress-of-Recordを指定する。これは、リクエストの最終的な受信者であるかもしれないし、そうでないかもしれない。
- Toタグ：ダイアログが確立していないリクエストはToタグをふくんではならない。
Contactヘッダ
Fromヘッダ/Toヘッダと役割が被っているようで被っていない...。Contactヘッダではきちんと「FQDN（IPアドレス）」と指定されている。
今後のリクエストを送信する場合の「送信先」を記述する。そのため「リクエスト」と「レスポンス」それぞれでContactヘッダの値は異なる。INVITEリクエストのみが含まれる。
Routeヘッダ
プロキシ関連のヘッダ
- Routeヘッダーフィールドは、リストされたプロキシのセットを経由してリクエストをルーティングさせるために使用される。
Record-Routeヘッダ
プロキシ関連のヘッダ
- Record-Routeヘッダーフィールドは、ダイアログ中のそれ以降のリクエストをプロキシを通してルートさせるために、そのプロキシによってリクエストに挿入される。
