はじめに

　SIPダイアログに関する話題が続いていますが、今回でいったん完結です！Part4では、early mediaフローの2つのモデルとENUMについて扱いたいと思います。

early mediaの2つのモデル

　early mediaのフローには、GatewayモデルとApplication Serverモデルの２つがあります。以下ではこの2つのモデルを詳細に見ていきます。

Gatewayモデル

　Gatewayモデルとは、一度early dialog上で確立されたearly mediaをcomformed mediaでも引き継ぐモデルです。そのためINVITEフローは以下のようになります。

これまで見てきたフローと同じですね！特徴としてはSDPの交換が1回のみです。実はこのモデルだとforkingを行う際にmedia clippingの問題が発生します。

forkingによるmedia clippingの問題

では、実際にforkingの問題を確認してみます。まずUACがプロキシに向かってINVITEを送信し、forkingによって複数のSIP端末へリクエストがコピーされたとします。

すると、このINVITEに対する暫定応答18xが発呼したUACにレスポンスされますね。これによって複数のearly dialogが確立することになります。問題はこの時のearly mediaの扱いです。

着信先の各sip端末が別々にearly mediaを送ってくるので、UAC側ではこれらの音声がミックスされて受信されることになります。そのような音声をユーザにそのまま届けてしまったら混乱を招いてしまうでしょう。そのため、発呼側UACでは、1つのearky session上のearly dialogをランダムや先着によって選択し、それ以外のearly mediaをミュートする必要があります。この時、ネットワークの帯域節約のために、着信先SIP端末側でRTPの再生を止めてもらうUPDATEリクエストを送る場合があります。

これで一つのsip端末のみとのealy mediaが確立されたわけですが、もしも着信先ユーザがealy mediaを確立していないsip端末で応答したらどうなるでしょうか。応答先sip端末のRTP送信は一時的に止められているので、着信先ユーザが話はじめでも発信先のユーザには聞こえないわけです。つまりmedia clippingが発生してしまいます。

では、forking時にmedia clippingを発生させないようにするにはどうすべきでしょうか？その答えは次に紹介するApplication Serverモデルを使うことです。

Application Serverモデル

　Application Serverモデルとは、明確にearly mediaとregular mediaを分割するモデルです。より具体的に言えばearly mmediaを引きつかずに、また新しいメディアセッションを確立します。そのためSDPもearly media用とregular media用で2つ交換します。具体的なINVITEフローの例を以下に示します。

このように、early sessionとregular sessionを明確に分離することで、たとえearly mediaを1つ選択してそれ以外の端末ではRTPのミュートを行ったとしても、regular mediaはミュートされていないため、着信応答後即座に通話を開始することができます。

また、Application Serverモデルでは、early mediaとregular mediaでメディアの送信元を変えるようなことも可能です。そのためIMSがearly media上でIVRを流し、regular mediaは別のUAからメディアを流す場合などにはApplication Serverモデルが利用されます。Application Serverモデルを利用するためには、sip extensionとして early-session tagを利用する必要があります。つまり、Supported/Requireヘッダに"early-session"を記述する必要があります。

ダイアログのまとめ

ここまででSIPのダイアログの基本的な部分を包括的に解説できたのではないかと思います。ここから話を少し変えて、ENUMについて扱いたいと思います。

DDDS