下図は簡略的に表現した図で、本来の SIP（Session Initiate Protocol）シーケンスはもう少し複雑です。
左のクライアントが常駐型で右がプッシュ型の場合です。
常駐型は直接、目的の SIP Proxy に REGISTER します。
REGISTER というのはロケーションサーバーに位置（IP アドレス）情報を登録することです。
この「位置登録」というのはレガシーな交換網の場合も同様のことを行っています。
IP アドレスの代わりに「ポイントコード」というアドレス体系で末端の電話機が収容されている交換機を管理していて、STP という信号線管理サーバーを通じてトランクを張る（回線をつなぐ）ようになっていますが、SIP も基本的には似ています。
位置登録のときに、SIP Proxy は配下のデータベースに問い合わせて認証処理を行うとともに課金準備をします。
一方、プッシュ型は Push Server（代行 SIP Proxy）がクライアントの REGISTER を受けて目的とする SIP Proxy に REGISTER 代行します。
Push Server はプッシュ型ソフトフォンベンダー（Sessiontalk Ltd. や Acrobits, s.r.o. など）、または ITSP（IP 電話事業者）が用意します。
Cloud ソフトフォンの場合で（SessionTalk Cloud や Cloud Softphoneなど）、ITSP がカスタマイズの一環で Push Server を用意するか、そうでない場合はソフトフォンベンダーのものが使われます。
Acrobits / SessionTalk (Pro) Softphone の場合はソフトフォンベンダーが用意したものです。
My050 / SMARTalk がどちらなのかは調べていないので不明ですが、ここでの記事は仕組みを記載していますので、どちらの Push Server でも仕組みは同じです。
本来の SIP Proxy は、この「代行 SIP Proxy」の位置登録を行い、「代行 SIP Proxy」はプッシュ型クライアントの位置登録をします。
左のクライアントから右のクライアントに発呼（INVITE）すると ③ ④ ⑤ と INVITE されて最終的に同一コーデックならば直接クライアント同士が通話ストリームのやり取りを行います。
コーデックが異なる場合は SIP Proxy がコーデックを変換します（しない場合は無音になります）。
通常、プッシュ型 SIP app はフォアグラウンドにあるときは本来の SIP Proxy にREGISTER し、バックグラウンドに落ちたタイミングで「代行 SIP Proxy」に REGISTER し直すようです。
「代行 SIP Proxy」は iPhone（または Android）のプッシュ機構を通じて端末にプッシュ信号を送り、これを受け取った端末は SIP app を起動し、INVITE を送り込みます。
いわゆる着信動作に入るわけです。
着信側が常駐型の場合は、バックグラウンドで動作中ですから、INVITE を受け取ります。
このときに何らかの原因でバックグラウンドで動作状態にないときは着信が失敗します。
REGISTER は一定間隔で行い続けますがこれが途切れた場合も着信が失敗します。
※ Push Server は SessionTalk の場合、以下の各都市に設置されており、
アプリでどこの Push Server を使うかを設定できるようになっています。
ヨハネスブルグ（南ア）、ロンドン（英）、ロンドン２（英）、
オレゴン（米・西部）、バージニア（米・東部）、サンパウロ（伯）、
バンガロア（印）、シンガポール、東京（日）、シドニー（豪）、
auto（おまかせ）
どこのサーバーを使うかによっては呼び出し時の多少の遅延はあっても
通話は通常端末同士のやり取りですので、サーバーの設置場所の影響は
ありません。
ですので Tokyo(Japan) / auto のいずれかでいいでしょう。
PUSH 通知は Android と iOS は概念的には同じです。
iOS のプッシュ機構には iOS ８ から VoIP PUSH が備わりました（下表）。
- アプリは Apple Push Notification Service（APNS）/ Google FCM にデバイストークンを要求します。
- アプリは、プッシュ通知を送信するアドレスとして機能するトークンを受け取ります。
- アプリは SIP REGISTER メッセージで Push Server (SIP Proxy) に登録します。 デバイストークンおよびその他の必要な情報をこのヘッダーに含めて、 REGISTERメッセージに「Push Server」ヘッダーを追加し、Push Server にこの拡張機能のプッシュ通知を受信したいことを知らせる必要があります。
- ユーザーがアプリケーションを強制終了します。
- 誰かが電話をかけたとき、そのアカウントの登録が期限切れになっていない場合、Push Server は「適切な連絡先アドレス」に INVITE メッセージを送信し、APNS / FCM にデバイストークンとともに「プッシュ通知」を送信します。
- アプリは終了しているので、 INVITE メッセージはアプリによって受信されません。
- APNS / FCM はデバイスに「プッシュ通知」を送信します。
- iOS / Android デバイスはそのプッシュ通知を受信し、モバイルデバイスに着信があることを警告します。
- アプリが起動され、Push Server に自動的に REGISTER (登録) されます。
- REGISTER (登録)が成功すると、push Server は新しい登録から取得した INVITEメッセージを連絡先アドレスに送信します。
- これで、アプリは INVITE メッセージを受信して電話に応答します。
Push ｎotification は WiFi <---> 4G (LTE) で IP アドレスが変わったりした場合は、常にプッシュ通知を受け取れるようにしています。
そして、「プッシュ通知」を受けたあと、アプリを起こしアプリは改めて最新の位置登録をするために REGISTER します。
そこに Push Server が INVITE を投げます。
ですので、アプリが未起動・消去（強制消去を含む）されていても、またその間に IP アドレスが変わっても正しく INVITE に応答できるわけです。
したがって、プッシュサーバーがどこに設置かで多少の遅延があっても、それは電話の呼び出しに対して０〜１秒程度の遅延でしかありませんし、音声は直に端末同士でやりとりなのでプッシュサーバーの設置位置の影響を受けないということです。
14 件のコメント:
はじめまして。いつもソフトフォンの記事をとても参考に拝見させていただいております。
MVNOでbrastelとsmartalkを使用しており、つい先日iPhone＆Acrobits系からバイク野郎さんの記事をきっかけにsessiontalkに乗り換えて使用感を試しているところなのですが、昨日うまくプッシュ着信できていない事に気づきました。
brastel＆smartalkとiphone環境は3台所有しており(iphone6,iphone6s,iphone7)いずれもプッシュ着信しない状況(厳密にはアプリをフォアグラウンドで立ち上げている状態では着信するが、バックグラウンドにするとプッシュしない。またこの状態では対象の電番にコールしてみるも呼び出しすらかからず通話が終了してしまう状態）
試しにプッシュServerLocationをJapanから(Autoでも症状が回復せず)他の国にしてみたところ、うまくプッシュ着信およびコールもできるようになりました。
Serverになんらか障害おきてるという事があるのかわかりませんが、バイク野郎さんのところでは何も問題は起きていないでしょうか。
こんにちは。
プッシュサーバーは不調なこともあるようです。
以前、Acrobits でもありましたし、公式アプリ（My050/SMARTalk）でもあるようです。
ワタシも Tokyo(Japan) が NG だったときに シンガポールに設定したら正常にプッシュされた、というのが１度ありました。
SMARTalk の場合はアカウントの設定->上級->その他->プッシュオプションの「プライベートIP」をオフにしてください。また「単一登録：オン」「同期の登録：オフ」「通話中の登録をブロック：オフ」に設定してください。
SMARTalk はこれらの設定をしないとプッシュ着信しません。
自宅 WiFi での利用時の場合、アカウントの「SIP 登録」の「失効時間」をルーターの udp タイムアウト時間よりも小さい値にすると改善されることもある、という報告があるようです。
ブラステルの SIP Proxy であれば再登録間隔（いわゆる失効期間）は概ね 100 秒以下でスので、udp タイムアウトになることは考えにくいのですが、プッシュの場合は SessionTalk の SIP Proxy なので、再登録間隔がいくらの数値間隔かは不明です。
したがって udp タイムアウト時間以下に設定してみることも意味があるかも知れません。
HGW の場合の udp タイムアウト値は 180 秒ですが、バッファローや IO-DATA 製ルーターはこれを変更できない機種が多く、設定値も公表されていません。
したがって、「失効期間」を 600-> 150〜90 くらいにしてみるのも手かも知れません。
さっそくのお返事ありがとうございます。
文章が非常に見にくくてすみませんでした。。。
バイク野郎さんでも同じ症状があったとの事、本当はこのような症状にならない事が望ましいのですが、自分の環境だけではなかったと、ほっとしました。
合わせていつかSMARTalkの設定の事を聞こうと思っていたところ、ご教示いただきありがとうございます。
プライベートIPオフ設定は強調されていたのですが、単一登録オン、同期の登録オフの変更は強調されていなかったので、デフォルトでいいのか少し迷っていました。
また、別にこの場をお借りして、お伺いしたいのですが、バイク野郎さんはBrastelの設定で 上級 > URL残高 は設定していらっしゃいますか。
Acrobitsの場合、
https://cloud.brastel.com/bcs/bcs-web-proxy/cloudphone/balance?username=ユーザー名&password=パスワード
と設定するとプリペイド残高が表示されるのですが、SessionTalkは試しに同様の設定をしてみましたが、見渡す限り表示されている気配がありませんでした。
そもそもURLの記述の仕方もSessionTalkに対しては間違っていそうですが。。。苦笑
これはワタシも以前に「URL残高」の設定項目に URL を記述しましたが残高は表示されませんね。
SessionTalk のホームページにある設定に関する記述にはこれに関する説明はありませんので、どういう場合に設定してどういうふうに機能するかがわかりません。
Acrobits / CloudSoftphone とは意味が違うのだと思います。
残高アナウンスが流れます（非常に煩わしい）し、残高表示の有無はワタシにとっては殆ど重要ではありません。
ブラステルには、表示するならば「有効期限」を表示してほしいですね。
「残高URL（Balance URL）」は、アカウントの新規追加時に「GENERIC（一般）」ではなく、その下にある ITSP（SessionTalk Cloudを使用する ITSP）向けの機能のようです。
これらの ITSP 以外の場合は有効ではないみたいです。
Sessiontalk Cloud ではなく SessionTalk Softphone でこれらの ITPS を設定するときの項目みたいです。
指定の仕方は https://example.com/…/balance?username=%name%&password=%passwd% でいいようですが、「一般向け」には開放されていないようですのでブラステルの場合は表示されないみたいですね。
ブラステルの My050 では表示されるが Acrobits ではそのままでは URL残高が表示されないので設定されて初めて表示される、という関係に似ています。
この場合の My050 に相当するのが SessionTalk Cloud で、Acrobits に相当するのが SessionTalk Softphone ということですね。
SIP登録 > 失効期間(レジストリ期限)
実はよく理解しておらず。。。
この設定はアプリをフォアグラウンドにした際に登録していると勝手に想像し
自分の使い方的には、ほぼバッググラウンド待機の方が多いこと
また、他所では長めに設定していた方がプッシュが安定するなどの情報もあり
一度の登録で長く情報を保持してくれる方がいいと思い86400秒(1日)を設定していたりしておりました
URL登録の件
なるほど仕組みを理解いたしました
わざわざお調べいただきありがとうございます！
探求する精神、仕組みを理解できる頭脳
本当に尊敬いたします
SIP では端末側が REGISTER し、SIP サーバー側がこれを受けて次回の REGISTER を何秒以内にしろ、という応答を返します。
この時間内に再度 REGISTER しないとサーバー側は端末に問題があったとみなして REGISTER を取り消します。
このときに端末側で初期値として設定した値が失効期間ですが、事実上意味はありません。なぜなら、サーバーが次の REGISTER は何秒以内にしてくれ、と要求するからです。
つまり、「REGISTER／200OK（応答）」を繰り返すことで、お互いに登録状態を確認保持しているわけです。
プッシュの場合は、プッシュサーバーがこの処理を代行します。
端末とプッシュサーバーの間では、通常最初の「REGISTER／200OK」以外には特には何もしないと思われます。
なぜかといいますと端末側のアプリはバックグランドからも消えて未起動状態にあると思われるからです。
ここでも、おそらく失効期間は事実上、意味をなさないと思われます。
図でご説明されていたように
SIPサーバー ＜ーー＞ プッシュサーバー
この間でREGISTER/応答をなげあい生存確認しているという事で認識あっていますでしょうか
となると
端末 ＜ーー＞ プッシュサーバー
の失効期間はどのようになるんだろうと次の疑問が。。。
フォアグラウンドで起動する毎に期間を更新するのだと思いますが、
バックグラウンドからも消えて未起動状態での失効期間は
プッシュサーバーの設定によるんですかね
ちなみにSMARTalkの場合、公式に以下の説明がありました
「SMARTalkを2週間以上起動していない場合、プッシュサーバへの登録がタイムアウトし、着信ができなくなります。 SMARTalkを起動することにより、再度着信ができる状態となります。」
ITSP の SIP Proxy <--> プッシュサーバー間は生存確認しているはずです。
なぜなら、これをしないと ITSP の SIP Proxy がタイムアウトで登録を削除してしまうからです。
端末 <--> プッシュ（SIP Proxy）サーバー間は失効期間が過ぎるまでは REGISTER 要求が有効とみなしますが、実際にはサーバーからは次の REGISTER は何秒以内にして、という時間が返されます。
失効期限を過ぎたとき、再 REGISTER するかどうかはアプリの作りによります。
SIP の動作の詳細がお知りになりたい場合は、https://tools.ietf.org/html/rfc3261 に記載されています。
プッシュサーバーもまた何らかの時間監視をしているはずですが、SessionTalk について情報がなくわかりません。
お世話になります
なんとなく仕組みを理解できました
教えていただきましたSIP動作の詳細
敷居が高いですが、バイク野郎さんの本記事と合わせて
少し自分でも勉強してみようと思います
ソフトフォンがバックグランドで未起動状態になっている事が
1週間から2週間はざらで、それでもプッシュで呼び出しはしてほしく・・・
少しでも仕組みを理解しておけば、柔軟に対応できるかなとお伺いさせていただいた次第です
今回もろもろ教えていただきまして本当にありがとうございました
ご理解の一助になればありがたく思います。
コメントを投稿