なんとなく実験 with SIProp開発記

吉澤さんの「SIPropの意義 / SIPの相互接続性問題を、NAT越え問題と対比して考える」のエントリーにて、

実際、「SIPには方言がある」ということ自体は関係者の間で周知されていると思うのですが、僕みたいに「SIPがどんなものか何となく知っている」程度の人間には、具体的にどういう問題があるのかさっぱり分かってないのではないでしょうか。

というところがありましたので、相互接続問題の大枠の整理をしてみたいと思います。
実際に詳細を見ていくと、大きく3つの問題に分かれることになります。


●トランザクション(SIPスタック)レベルの問題
こちらは、どのくらいRFCに準拠しているか や RFCの曖昧さから出てくる問題点となります。

たとえば、ダイアログ(セッション)を終了するBYEの問題があります。
RFC的には、

既存ダイアログ外のBYEに対する応答は、既存ダイアログが見つからなかったことを示す481応答を返すべきである[SHOULD]

とされています。
BYEは、既存ダイアログを終了させるメソッドであるため、その終了させるべきダイアログがなければ、481応答を返すことは妥当のように思われます。

しかし、違う考え方もあります。
それは、BYEというトランザクションレベル(リクエスト〜レスポンスまで)で処理を考えた場合です。
その場合、たとえ終了させるべきダイアログがなく、BYEのセッション終了としての動作は失敗したとしても、BYEトランザクションとして正常に処理されれば、BYEトランザクションとして200OK応答を返すという考え方です。
この動作は、トランザクション動作としては正しいですし、BYEのセッション終了としても481応答が[SHOULD]であるため、RFC的には問題ない動作となります。

そして、これを現場レベルの視点で見ると、

481応答を返すには、BYEのダイアログに対して、既存ダイアログをチェックするルーチンが必要になる → 工数が増える！！！

という課題が出てきます。
そのため、SIProp的に制約条件といっているものが考慮されて、RFC推奨の481応答実装ではなく、200OK応答実装がされてしまう場合があり、ダイアログ外のBYEに対する応答に2種類の実装が存在してしまうのです。

●シーケンス(UA・機能)レベルの問題
基本的に、RFCでは、トランザクションの定義はありますが、シーケンス(機能)に関する定義はありません。そのため、SIPをPBXのプロトコルとして使用する場合には、独自でシーケンス(機能)を定義する必要があるのです。
※一部「draft-ietf-sipping-service-examples」にて、シーケンスの推奨仕様が示されています。

たとえば、電話でよく使用される保留機能(保留シーケンス)があります。
シーケンス(機能)の推奨仕様「draft-ietf-sipping-service-examples」には、「Re-INVITEにより保留音に変更する」と「Mediaサーバへの転送する」の二つが提案されています。
しかし、日本における実サービスとしては、「マイクとスピーカをミュートし、音声を保留音に変更する」というSIPを一切使用しない独自実装になっていることが多いです。

これは、保留機能というものが、 RFCのSIPの仕様外の機能である点 と 各社が独自に持っているPBXとの整合性を取るために独自にシーケンス(機能)を定義して実装 してしまっているからです。
（もちろん、SIProp的に制約条件といっているものが考慮されている場合もあります。)
そのため、「保留機能」といっても、何種類ものシーケンス(機能)が存在してしまうのです。特に、この場合は、シーケンス(機能)自体が変わってしまうため、相互接続問題が発生してしまいます。

●スペック(機能仕様)レベルの問題
これは、プロトコル的には、シーケンス(UA・機能)レベルの問題と同じではあるのですが、UAとしては、影響が出るものなので、ここでは別としています。
こちらは、同じ名称でも、具体的には別物というものとなります。

たとえば、電話でよく使用される留守電機能(留守電シーケンス)があります。

・家庭用電話機では、電話機自体に留守電を保存し、再生します。
・ケータイでは、キャリア側(サーバ側)に留守電を保持し、再生することもできます。
・PBXでは、留守電メッセージをMP3などに変換して、メールで送信する機能もあったりします。

というように、一口に「留守電機能」といっても、端末メーカーやPBXメーカーにより、スペック(機能仕様)自体が全く違っていたりするのです。
上記の例では、ケータイでは、家庭用電話機のようにケータイ端末自体に録音する機能も持っており、「留守電機能」といっても2種類の機能があるわけです。

これで、さらにやっかいなものは、別の名称なのに、実は、同じ機能などもあり、問題を複雑にしています。グループ着信や代表着信などは、その最たる例です。

こういった感じで、SIPの相互接続問題といっても、Stackレベルからスペックレベルまで複雑に絡み合っているのです。