1 概要
050plus は VoIP (Voice Over IP) とSIP (Session Initiation Protocol) を使ってインターネット上で音声通話をするNTTコミュニケーションズ社が提供するサービス（だと思います）です。従って、いわゆる汎用SIPクライアントソフトウェア（アプリ）にパラメタを設定してやれば、NTTコミュニケーションズ社が提供する050plus専用アプリでなくてもサービスを使うことができます。
これこそ国際標準プロトコル技術仕様の存在価値です。国際標準で規定している部分は互換性が確保されます。その上で、電話としての機能性や使い勝手という付加価値で市場競争を行うことによって、きちんとシグナリングして通話ができた上で利用者ユースケースに合ったSIPクライアントアプリを自由に選べる状況ができるというわけです。例えば、NTTコミュニケーションズ社の純正050plusアプリは着信音（マナーモードのときにはバイブ）が1回しか鳴らないという上位層仕様になっていますが、Acrobits Softphoneアプリは普通に鳴り続けてくれるという上位層仕様になっています。どちらのアプリもVoIP及びSIPが国際標準規格に適合ならば後は上位層（操作性など）の味付けの違いで自分の使い勝手に合ったアプリを選べばよいというわけ。
050plusサービスは、VoIPとSIPを使って提供されているサービスなのかどうか、確かめてみることにしました。SIPクライアントとして iPhone5 (iOS 9.1) で Acrobits Softphone (バージョン 5.8 build BD4CF) を使いました。iPhone 6 Plus (iOS 10.3.3) で Acrobits Softphone (バージョン5.8.6 64 bit build E3B4F) を使った時も同じでした。
Acrobits Softphone is the leading SIP client for iPhone, iPad and iPod Touch. Set it up with a VoIP provider of your choice and start making cheap calls over WiFi or 3G from your mobile device. You can also receive VoIP incoming calls anywhere using our Push Notification service or iOS 4 background mode.
http://www.acrobits.net
2 050plus用設定パラメタの取得
先ず手始めは Acrobits Softphone アプリに設定するべき 050plus サービス用のパラメタの取得です。以下を sip.html という名前のテキストファイルに保存してダブルクリックするとブラウザ（MacOSXの場合ならSafari）が開きます。
sip.htmlをブラウザで開いた画面に050plusの電話番号及びパスワードを入力してから一番下にある情報取得ボタンを押しますと画面が切り替わり画面に情報が１行で表示されます。その画面をテキストとしてそのまま保存すると InitSet.aspx.xml というファイル名のテキストになります。その内容は次の通りです。
3 Acrobits Softphoneアプリの設定
上記2で取得した情報から下記の項目を拾い上げて Acrobits Softphone アプリに設定します。
ユーザ名（nicNm）：fmc12349999
SIPアカウント（sipID）：ABCDEFGH
SIPパスワード（sipPwd）：PASSWORD
SIPプロキシサーバアドレス（tranGwAd）：kar2-f2fcp.050plus.com
承認されたユーザー名[Auth User Name]（sipID）：ABCDEFGH
プロキシ[Proxy]（tranGwAd）：kar2-f2fcp.050plus.com
トランスポートプロトコル[Transport Protocol]：tls(sip)を選ぶ
着信：プッシュで
3Gで利用可能なコーデック：G.729a（←これを購入しましたが無くてもOK）
-----
シングル登録 [Single Instance]：オフ→オン
通話中の登録をブロックする[Block Registration During Call]：オフ→オン
キープアライブ時間[Keepalive Period]：30→60
期限：600→3600（レジストリー反映期限。サーバーはこの値を利用します）
NAT通過：利用しない→利用する
ホスト：kar2-f2fcp.050plus.com
トランスポートプロトコル[Transport Protocol]：tls(sip)を選ぶ
安全な通話：着信：利用する
安全な通話：発信：不可→ベストエフォート
4 実験結果
発信：特に問題ない模様です。
着信：プッシュで確実に着信します特に問題ない模様です。
通話：特に問題ない模様です。
切断：問題有りました。
Xperia X Perfomance (au SIM, 090番号) から発信
↓
iPhone 5 (Y!mobileデータ通信専用SIM, Acrobits Softphone: 050plus に設定) に着信
↓
相互に音声通話可能であることを確認
↓
iPhone側で電話を切る
↓
Xperia側も自動的に切れなければなりませんが切れません
↓
1分か1分半程経過してからやっとXperia側も切れました
5 分析
着信側が電話を切ったのに発信側の電話が切れないというのは、普通ではないと思います。発信側が気付かなければ、この1分か1分半は課金される可能性が高いと考えられます。この状況について、Acrobits Softphone アプリに備わっている通信ログ機能を使って取得したログを Acrobits 社に送って診てもらいました。
Acrobits社の担当者の見立ては次の通りです。Acrobits Softphone が BYE を送信すると 050plus (SIPサーバ) がなぜか接続を切断してしまっているのが問題の原因なのではないかとの疑いがあります。この場面では、TLS接続を切断すべきではなくて BYE への応答を行うべき状況です。即ちAcrobits Softphoneアプリの側ではなくて 050plus (SIPサーバ) 側の問題によって不都合が生じているという整理が一般論だと考える。この場面でTLS接続を切断する理由を示してもらえれば Acrobits Softphone アプリ側で対応できるかもしれません。
さて、少々穿ち過ぎかもわかりませんが、050plus (SIPサーバ) にこのような仕掛けをしておくことで、「BYEに応答する代わりにTLS接続の切断をしてしまう」ことで、およそ1分か1分半の課金を余分にしてやろうというセコイ考えなのかしらん？
Acrobits Softphone 側で終話したら相手側もその直後に切断されねば困るのにそうならないという現象は、2012年にはすでに発覚していたことをネットの掲示板で見つけましたので下に引用します。
| 2012/07/07(土) 00:39:30.15
| 公式アプリ使うよりAcrobits & G711 u-Lawで使う方が音質いい
| ただし、Acrobitsからの終話で、相手側も切断されれば完璧なんだが...
|
| 2012/07/07(土) 00:57:31.62
| Acrobits使ってるけど相手側はこっちが切断したら相手側は切断されないの？
|
| 2012/07/07(土) 08:25:27.19
| Acrobitsから固定、ドコモケータイ、050plus公式アプリ宛へ
| それぞれにかけてみましたが、全ての回線において、
| こちらが切ると相手側は、無音状態の通話中が続きます。
|
| 2012/07/07(土) 13:25:44.49
| 今やったが、終話できたけど
|
| 2012/07/07(土) 19:20:11.80
| 大袈裟に聞いてしまいますが、10回位試して全てOKですか？
| こちらは成功率0%のもので。
| 良かったら、設定内容を欲しいです。
これの後を受けて設定内容をやり取りした形跡は見つかりませんでしたので、やはり Acrobits Softphone 側で終話しても相手側がその直後に切断されないというのは2012年には発覚しているにもかかわらず、5年経過した今でも解決されぬままという整理になると思います。
6 評価
050plusサービスはVoIP及びSIP仕様を採用していますので、いわゆる汎用SIPアプリを使ってサービスを利用できますが、接続（呼）を切断する際のプロトコルだけが国際標準に適合していない。だから電話を掛けた側で1分か1分半程余分に課金されてしまう危険性がある。それでもよければ Acrobits Softphone で 050plus サービスを利用できると言って良さそうだ。
7 参考
(1) 自己満足備忘録（2014-03-09）「050plus」のSIP情報取得〜固定電話として使うまで
(2) acrobits softphoneでFusion IP-Phoneと050plusを使う（2013-02-08）
(3) （一社）日本ネットワークインフォメーションセンター JPNICのホームページから以下に一部抜粋：
SIPの基本
SIPを規定するRFC3261は、269ページに及ぶ非常に厚みのあるRFCです。それだけ、膨大な規定が必要になるということを示しています。ここでは、そのすべてをご紹介することはできませんので、概要を述べるにとどめます。SIPは、端末（User Agent:UA）間でセッションの生成、変更、切断を行うのみのプロトコルで、セッション上で交換されるデータそのものについては定めていません。従って、アプリケーションが、SIPによって制御されたセッション上で、音声のやりとりを行えばIP電話、音声と映像ならばテレビ電話、テキストメッセージならばインスタントメッセンジャーというように幅広い応用が可能となります。次に、例としてAliceがBobへIP電話をかける場合を想定して、そのセッションの過程を概観します。ここで出てくる機器は、AliceとBobのIP電話機（=UA）、各IP電話機の収容するSIPプロキシサーバA（atlanta.com）とB（biloxi.com）です。SIPプロキシサーバは、公衆電話交換網で言うならば、交換機のようなもので、UAやプロキシからのリクエストを受け取り、適切なUA、プロキシへ送信を行います。通話開始から終了までにおけるやりとりは、図1のようになります。
図1: IP電話セッション確立から切断までの例（参考:RFC3261）
セッションの確立は、INVITE（招待）メッセージ送信から始まります。SIPにおけるUAの識別は、sip:alice@atlanta.com、sip:bob@biloxi.comのようにURI（Uniform Resource Identifier）形式で行い、AliceはBobとのセッション確立のために、sip:bob@biloxi.comへINVITEメッセージを送信します（図1の左上の方にある(1)INVITE）。
図2は、AliceからBobへのINVITEメッセージの例です。
このメッセージ形式からわかるように、SIPではアスキーで記述されているため、メッセージの内容を可読できます。そして、形式がHTTPやSMTPに似ているため、容易に内容を理解できます。INVITEを受信したプロキシAでは、宛先が、bob@ biloxi.comであることから、biloxi.comのプロキシBへINVITEメッセージを送信します（図1の(2)）。また、プロキシAは、Aliceへ「プロキシBへのINVITEを実行中である」ことを通知する暫定応答100Tryingを送信します（図1の(3)）。この「100」とは、要求に対する結果を示すステータスコードで、図3に示すようにHTTPで定めたステータスコードを拡張した仕様となっています。
図3: ステータスコード
プロキシBは、受信したINVITE（図1の(2)）から、配下のBobへINVITEを送信します（図1の(4)）。INVITEを受信したBobは、電話のベルを鳴らすなど相手からの呼び出し処理を行い、併せて、発信元（Alice）へ呼び出し中であることを伝えるため、暫定応答180RingingをプロキシBへ応答し、180 Ringingは、Aliceへ転送されます（図1の(6)と(7)と(8)）。Bobは、受話器のオフフック（受話器をあげる）などによって、成功200OKをプロキシB/Aを経由してAに送信します（図1の(9)と(10)と(11)）。Aliceは、Bobからの200OKを元にACK応答（セッション確立了解）をBobへ送信し（図1の(12)）、AliceとBobの間にセッションが生成されます。生成されたセッション上で、音声データがやりとりされ、通話状態となります。そして、Bob上の受話器がオンフックとなったとき、BYE要求（セッション切断要求）と200OK応答によって、セッションが終了し、通話が終了します（図1の(13)と(14)）。以上に簡単ではありますが、SIPの概要を説明致しました。SIPのシグナリングは、シンプルで、また、HTTPやSMTPに似ていることから、理解しやすく、実装もしやすいことがお分かりいただけたかと思います。今回紹介したのは、SIPのほんの一部の部分です。このほかにも、様々な仕組みが存在します。興味のある方は、RFCなど文献をご参照ください。
SIPと相互接続性
昨今、企業内でのVoIP化や、ブロードバンドの普及に伴うコンシューマー市場におけるVoIP化によって、種々のVoIP端末（UA）が登場してきています。その普及に従って、VoIP機器同士の相互接続性が問題となっています。一般的に考えて、IETFが標準化したプロトコルであるSIPを実装したIP電話やサーバ（VoIP交換機）間ならば、相互接続が可能であると考えるでしょう。しかしながら、現状、残念なことに相互接続がうまくいかない場合があります。VoIP機器は、登場当初から、閉じたシステムである傾向が強かったため、サーバ（VoIP交換機）とIP電話機がセットで開発され、独自拡張などが施される場合もあります。また、ベンダー毎にURIの表記方法が異なっていたり、RFCが厳密に定義していない点などが影響して、SIPに対応した製品同士やVoIP事業者同士の相互接続が保証できていません。この問題点を解決するために、規格面・実装面からの相互接続性の実現に向けての活動が行われています。規格面では、（社）情報通信技術委員会（TTC）が、相互接続に必要な仕様の策定をしています。実装面では、（社）テレコムサービス協会 VoIP推進協議会 相互接続作業班や高度通信システム相互接続推進会議において、ベンダー間（端末とサーバ）の相互接続性の検証が行われており、VoIP/SIP相互接続検証タスクフォースにおいては、VoIP事業者間における相互接続の検証が進められています。
各所における相互接続検証活動を通して、問題は解決方向にむかっていっているといえます。
050plus は VoIP (Voice Over IP) とSIP (Session Initiation Protocol) を使ってインターネット上で音声通話をするNTTコミュニケーションズ社が提供するサービス（だと思います）です。従って、いわゆる汎用SIPクライアントソフトウェア（アプリ）にパラメタを設定してやれば、NTTコミュニケーションズ社が提供する050plus専用アプリでなくてもサービスを使うことができます。
これこそ国際標準プロトコル技術仕様の存在価値です。国際標準で規定している部分は互換性が確保されます。その上で、電話としての機能性や使い勝手という付加価値で市場競争を行うことによって、きちんとシグナリングして通話ができた上で利用者ユースケースに合ったSIPクライアントアプリを自由に選べる状況ができるというわけです。例えば、NTTコミュニケーションズ社の純正050plusアプリは着信音（マナーモードのときにはバイブ）が1回しか鳴らないという上位層仕様になっていますが、Acrobits Softphoneアプリは普通に鳴り続けてくれるという上位層仕様になっています。どちらのアプリもVoIP及びSIPが国際標準規格に適合ならば後は上位層（操作性など）の味付けの違いで自分の使い勝手に合ったアプリを選べばよいというわけ。
050plusサービスは、VoIPとSIPを使って提供されているサービスなのかどうか、確かめてみることにしました。SIPクライアントとして iPhone5 (iOS 9.1) で Acrobits Softphone (バージョン 5.8 build BD4CF) を使いました。iPhone 6 Plus (iOS 10.3.3) で Acrobits Softphone (バージョン5.8.6 64 bit build E3B4F) を使った時も同じでした。
Acrobits Softphone is the leading SIP client for iPhone, iPad and iPod Touch. Set it up with a VoIP provider of your choice and start making cheap calls over WiFi or 3G from your mobile device. You can also receive VoIP incoming calls anywhere using our Push Notification service or iOS 4 background mode.
http://www.acrobits.net
2 050plus用設定パラメタの取得
先ず手始めは Acrobits Softphone アプリに設定するべき 050plus サービス用のパラメタの取得です。以下を sip.html という名前のテキストファイルに保存してダブルクリックするとブラウザ（MacOSXの場合ならSafari）が開きます。
sip.htmlをブラウザで開いた画面に050plusの電話番号及びパスワードを入力してから一番下にある情報取得ボタンを押しますと画面が切り替わり画面に情報が１行で表示されます。その画面をテキストとしてそのまま保存すると InitSet.aspx.xml というファイル名のテキストになります。その内容は次の通りです。
3 Acrobits Softphoneアプリの設定
上記2で取得した情報から下記の項目を拾い上げて Acrobits Softphone アプリに設定します。
ユーザ名（nicNm）：fmc12349999
SIPアカウント（sipID）：ABCDEFGH
SIPパスワード（sipPwd）：PASSWORD
SIPプロキシサーバアドレス（tranGwAd）：kar2-f2fcp.050plus.com
承認されたユーザー名[Auth User Name]（sipID）：ABCDEFGH
プロキシ[Proxy]（tranGwAd）：kar2-f2fcp.050plus.com
トランスポートプロトコル[Transport Protocol]：tls(sip)を選ぶ
着信：プッシュで
3Gで利用可能なコーデック：G.729a（←これを購入しましたが無くてもOK）
-----
シングル登録 [Single Instance]：オフ→オン
通話中の登録をブロックする[Block Registration During Call]：オフ→オン
キープアライブ時間[Keepalive Period]：30→60
期限：600→3600（レジストリー反映期限。サーバーはこの値を利用します）
NAT通過：利用しない→利用する
ホスト：kar2-f2fcp.050plus.com
トランスポートプロトコル[Transport Protocol]：tls(sip)を選ぶ
安全な通話：着信：利用する
安全な通話：発信：不可→ベストエフォート
4 実験結果
発信：特に問題ない模様です。
着信：プッシュで確実に着信します特に問題ない模様です。
通話：特に問題ない模様です。
切断：問題有りました。
Xperia X Perfomance (au SIM, 090番号) から発信
↓
iPhone 5 (Y!mobileデータ通信専用SIM, Acrobits Softphone: 050plus に設定) に着信
↓
相互に音声通話可能であることを確認
↓
iPhone側で電話を切る
↓
Xperia側も自動的に切れなければなりませんが切れません
↓
1分か1分半程経過してからやっとXperia側も切れました
5 分析
着信側が電話を切ったのに発信側の電話が切れないというのは、普通ではないと思います。発信側が気付かなければ、この1分か1分半は課金される可能性が高いと考えられます。この状況について、Acrobits Softphone アプリに備わっている通信ログ機能を使って取得したログを Acrobits 社に送って診てもらいました。
Acrobits社の担当者の見立ては次の通りです。Acrobits Softphone が BYE を送信すると 050plus (SIPサーバ) がなぜか接続を切断してしまっているのが問題の原因なのではないかとの疑いがあります。この場面では、TLS接続を切断すべきではなくて BYE への応答を行うべき状況です。即ちAcrobits Softphoneアプリの側ではなくて 050plus (SIPサーバ) 側の問題によって不都合が生じているという整理が一般論だと考える。この場面でTLS接続を切断する理由を示してもらえれば Acrobits Softphone アプリ側で対応できるかもしれません。
さて、少々穿ち過ぎかもわかりませんが、050plus (SIPサーバ) にこのような仕掛けをしておくことで、「BYEに応答する代わりにTLS接続の切断をしてしまう」ことで、およそ1分か1分半の課金を余分にしてやろうというセコイ考えなのかしらん？
Acrobits Softphone 側で終話したら相手側もその直後に切断されねば困るのにそうならないという現象は、2012年にはすでに発覚していたことをネットの掲示板で見つけましたので下に引用します。
| 2012/07/07(土) 00:39:30.15
| 公式アプリ使うよりAcrobits & G711 u-Lawで使う方が音質いい
| ただし、Acrobitsからの終話で、相手側も切断されれば完璧なんだが...
|
| 2012/07/07(土) 00:57:31.62
| Acrobits使ってるけど相手側はこっちが切断したら相手側は切断されないの？
|
| 2012/07/07(土) 08:25:27.19
| Acrobitsから固定、ドコモケータイ、050plus公式アプリ宛へ
| それぞれにかけてみましたが、全ての回線において、
| こちらが切ると相手側は、無音状態の通話中が続きます。
|
| 2012/07/07(土) 13:25:44.49
| 今やったが、終話できたけど
|
| 2012/07/07(土) 19:20:11.80
| 大袈裟に聞いてしまいますが、10回位試して全てOKですか？
| こちらは成功率0%のもので。
| 良かったら、設定内容を欲しいです。
これの後を受けて設定内容をやり取りした形跡は見つかりませんでしたので、やはり Acrobits Softphone 側で終話しても相手側がその直後に切断されないというのは2012年には発覚しているにもかかわらず、5年経過した今でも解決されぬままという整理になると思います。
6 評価
050plusサービスはVoIP及びSIP仕様を採用していますので、いわゆる汎用SIPアプリを使ってサービスを利用できますが、接続（呼）を切断する際のプロトコルだけが国際標準に適合していない。だから電話を掛けた側で1分か1分半程余分に課金されてしまう危険性がある。それでもよければ Acrobits Softphone で 050plus サービスを利用できると言って良さそうだ。
7 参考
(1) 自己満足備忘録（2014-03-09）「050plus」のSIP情報取得〜固定電話として使うまで
(2) acrobits softphoneでFusion IP-Phoneと050plusを使う（2013-02-08）
(3) （一社）日本ネットワークインフォメーションセンター JPNICのホームページから以下に一部抜粋：
SIPの基本
SIPを規定するRFC3261は、269ページに及ぶ非常に厚みのあるRFCです。それだけ、膨大な規定が必要になるということを示しています。ここでは、そのすべてをご紹介することはできませんので、概要を述べるにとどめます。SIPは、端末（User Agent:UA）間でセッションの生成、変更、切断を行うのみのプロトコルで、セッション上で交換されるデータそのものについては定めていません。従って、アプリケーションが、SIPによって制御されたセッション上で、音声のやりとりを行えばIP電話、音声と映像ならばテレビ電話、テキストメッセージならばインスタントメッセンジャーというように幅広い応用が可能となります。次に、例としてAliceがBobへIP電話をかける場合を想定して、そのセッションの過程を概観します。ここで出てくる機器は、AliceとBobのIP電話機（=UA）、各IP電話機の収容するSIPプロキシサーバA（atlanta.com）とB（biloxi.com）です。SIPプロキシサーバは、公衆電話交換網で言うならば、交換機のようなもので、UAやプロキシからのリクエストを受け取り、適切なUA、プロキシへ送信を行います。通話開始から終了までにおけるやりとりは、図1のようになります。
図1: IP電話セッション確立から切断までの例（参考:RFC3261）
セッションの確立は、INVITE（招待）メッセージ送信から始まります。SIPにおけるUAの識別は、sip:alice@atlanta.com、sip:bob@biloxi.comのようにURI（Uniform Resource Identifier）形式で行い、AliceはBobとのセッション確立のために、sip:bob@biloxi.comへINVITEメッセージを送信します（図1の左上の方にある(1)INVITE）。
図2は、AliceからBobへのINVITEメッセージの例です。
このメッセージ形式からわかるように、SIPではアスキーで記述されているため、メッセージの内容を可読できます。そして、形式がHTTPやSMTPに似ているため、容易に内容を理解できます。INVITEを受信したプロキシAでは、宛先が、bob@ biloxi.comであることから、biloxi.comのプロキシBへINVITEメッセージを送信します（図1の(2)）。また、プロキシAは、Aliceへ「プロキシBへのINVITEを実行中である」ことを通知する暫定応答100Tryingを送信します（図1の(3)）。この「100」とは、要求に対する結果を示すステータスコードで、図3に示すようにHTTPで定めたステータスコードを拡張した仕様となっています。
図3: ステータスコード
プロキシBは、受信したINVITE（図1の(2)）から、配下のBobへINVITEを送信します（図1の(4)）。INVITEを受信したBobは、電話のベルを鳴らすなど相手からの呼び出し処理を行い、併せて、発信元（Alice）へ呼び出し中であることを伝えるため、暫定応答180RingingをプロキシBへ応答し、180 Ringingは、Aliceへ転送されます（図1の(6)と(7)と(8)）。Bobは、受話器のオフフック（受話器をあげる）などによって、成功200OKをプロキシB/Aを経由してAに送信します（図1の(9)と(10)と(11)）。Aliceは、Bobからの200OKを元にACK応答（セッション確立了解）をBobへ送信し（図1の(12)）、AliceとBobの間にセッションが生成されます。生成されたセッション上で、音声データがやりとりされ、通話状態となります。そして、Bob上の受話器がオンフックとなったとき、BYE要求（セッション切断要求）と200OK応答によって、セッションが終了し、通話が終了します（図1の(13)と(14)）。以上に簡単ではありますが、SIPの概要を説明致しました。SIPのシグナリングは、シンプルで、また、HTTPやSMTPに似ていることから、理解しやすく、実装もしやすいことがお分かりいただけたかと思います。今回紹介したのは、SIPのほんの一部の部分です。このほかにも、様々な仕組みが存在します。興味のある方は、RFCなど文献をご参照ください。
SIPと相互接続性
昨今、企業内でのVoIP化や、ブロードバンドの普及に伴うコンシューマー市場におけるVoIP化によって、種々のVoIP端末（UA）が登場してきています。その普及に従って、VoIP機器同士の相互接続性が問題となっています。一般的に考えて、IETFが標準化したプロトコルであるSIPを実装したIP電話やサーバ（VoIP交換機）間ならば、相互接続が可能であると考えるでしょう。しかしながら、現状、残念なことに相互接続がうまくいかない場合があります。VoIP機器は、登場当初から、閉じたシステムである傾向が強かったため、サーバ（VoIP交換機）とIP電話機がセットで開発され、独自拡張などが施される場合もあります。また、ベンダー毎にURIの表記方法が異なっていたり、RFCが厳密に定義していない点などが影響して、SIPに対応した製品同士やVoIP事業者同士の相互接続が保証できていません。この問題点を解決するために、規格面・実装面からの相互接続性の実現に向けての活動が行われています。規格面では、（社）情報通信技術委員会（TTC）が、相互接続に必要な仕様の策定をしています。実装面では、（社）テレコムサービス協会 VoIP推進協議会 相互接続作業班や高度通信システム相互接続推進会議において、ベンダー間（端末とサーバ）の相互接続性の検証が行われており、VoIP/SIP相互接続検証タスクフォースにおいては、VoIP事業者間における相互接続の検証が進められています。
各所における相互接続検証活動を通して、問題は解決方向にむかっていっているといえます。