FaceTimeは動くのにMacからiPhone経由で発信できない理由
FaceTimeの通話が成功しても、MacでiPhone経由の発信リレーが動く証拠にはなりません。VPNが遮断しうるローカル経路を確認し、正しい順序で検証してください。
MacからFaceTimeの音声通話を問題なく開始でき、同じMacから業者の番号をダイヤルすると何も起きない。よくある解釈は、ネットワークは健全で無関係な何かが壊れたというものだ。その解釈こそが俗説であり、たいてい生き残るのはFaceTimeが公平なテストに見えるからにすぎない。
そうではない。FaceTimeの音声と電話リレーは別個の転送方式であり要件も別で、片方はもう片方が越えられないトンネルを通過する。
VPNも既定で犯人ではない。以下の順序は、別の設定に触る前に両方の前提を外す。
FaceTimeが通っても分かることはほとんどない
FaceTimeの音声は到達可能な相手との接続を交渉する。両端がパケットを交換できれば、その通信はインターネットを越えられ、フルトンネルのVPNも通る。電話リレーは建物の外に出ない。Macは近くのiPhoneに自分のセルラー回線で発信するよう依頼し、その要求はローカルにとどまる。
つまりFaceTimeの通話が成功しても、Macに使えるインターネットがありAppleのサービスに届くことしか分からない。隣にいるiPhoneが見えているかは何も語らない。二台の機器は同じSSIDを共有していても互いに見えないことがある。
この一文に俗説のすべてがある。建物の外に出る通話はローカルの経路を一切テストしない。
リレー経路が実際に要求するもの
Appleの一覧にある項目はすべて必須で、追加ではない。両方の機器が同じWi-Fiネットワークにあり、どちらも同じApple Accountでサインインし、どちらも電話番号を有効にしたFaceTimeにサインインし、使いたいMacで「他のデバイスでの通話」がオンになっている必要がある。AppleのiPhone通話ガイドが現在の表現の出典だ。
新しいiPhoneではスイッチは「設定」の「App」、「電話」、「他のデバイスでの通話」にあり、Macがその一覧に表示されて有効になっていなければならない。Macが最初に回線を使おうとすると、macOSはそのiPhoneからの通話を許可するか尋ねる。この確認を一度消すと、二度と尋ねられないため、機能は静かに壊れたままになる。
Mac側はシステムのバージョンで変わる。新しいmacOSには「電話」Appがあり、古いものはFaceTime経由で通話を転送する。手順がメニューを示しているのに見つからない場合は、設定が無いと決める前にバージョンを確認する。
| Requirement | How it fails when missing |
|---|---|
| Same Wi-Fi network | The iPhone is listed in settings but a call rings nowhere |
| Same Apple Account | The iPhone never appears as a call source |
| Number enabled in FaceTime | FaceTime calls work, the phone line does not appear |
| Calls on Other Devices enabled for this Mac | Incoming calls never arrive, outgoing dialing fails at once |
| macOS allow prompt accepted | Worked once after setup, then stopped without an error |
VPNが本当に邪魔をする場所
VPNクライアントはリレーを三通りに壊しうるが、文書化されているのは一つ目だけだ。文書化された例は、ローカルネットワークを妨げる構成である。macOSはそのようなVPNがContinuity機能を妨げる可能性があると警告し、リレーはContinuity機能だ。二つ目はフルトンネルで、MacがiPhoneに届くために使う通信を捕捉するため、ローカルの要求は用のないゲートウェイへ出ていく。三つ目は、フィルタやキルスイッチをトンネルだけでなくすべてのインターフェースに適用するクライアントだ。
社内サブネットだけを運ぶスプリットトンネルは、通常ローカルの経路をそのままにする。だから同じMacが一方のVPNプロファイルでは通り、別のプロファイルでは失敗する。両者の違いこそが有用な信号だ。
比較が何を証明するかには厳しくあれ。VPNなしで動き、VPNありで失敗するのは相互作用であって診断ではない。遮断されたプロトコル、ポート、インターフェースを名指ししておらず、それだけから経路をでっち上げれば次のテストは無意味になる。
VPNのせいにされる三つの失敗
Wi-Fi通話。これはiPhone側のキャリア機能であり、Macが引き継ぐものではない。電話がキャリアのサービスをWi-Fi経由で使えるようにするもので、すべてのキャリアが提供しているわけではなく、iPhoneの電源が切れている、圏外、またはキャリアのエンドポイントを遮断するネットワーク上では役に立たない。本当の要件が「iPhoneを家に置いたまま発信する」ことなら、リレーは最初から間違った仕組みを試していたことになる。
ネットワーク分離。ゲストネットワーク、アクセスポイントのクライアント分離、別個のVLANは、まさにリレーの症状を生む。同じSSIDで互いに見えず、VPNは関係ない。建物のWi-Fiがクライアントを分離しているなら、Macの設定では結果は変わらない。
Handoff。Handoffはデバイス間で作業を引き継ぐ。Macにセルラー回線を渡すものではなく、代わりのテストにもならない。Handoffのアイコンが出るのは二台が互いを見つけられる証拠ではあるが、通話のルーティングが動く証明にはほど遠い。
証拠が残る検証の順序
既知の状態から始める。iPhoneはロック解除して近くに置き、両方の機器を同じWi-Fiにつなぎ、MacのVPNは切っておく。発信を一度、着信を一度行う。失敗する理由が違うので、両方向とも意味がある。発信はMacが回線に届くかにかかり、着信はiPhoneがそのMacを有効な宛先と見なすかによる。
実際に使っているプロファイルでVPNを再接続し、他は何も変えずに両方の通話を繰り返す。どちらも通ればVPNは変数ではないので、調整をやめるべきだ。どちらも壊れるなら、プロファイル名、クライアントのバージョン、ローカル通信を除外しているかを記録し、その三点を設定の所有者に渡す。
片方向だけ失敗する場合は、トンネルより先にiPhoneの通話設定を見る。非対称な失敗はルーティングの問題よりも機器ごとのスイッチであることのほうがはるかに多く、その観察ひとつで半日が節約できる。
エスカレーション前に確認すること
次の五項目を順に確認し、それぞれ答えを書き留める。同じWi-Fiネットワーク、同じApple Account、FaceTimeで有効な電話番号、「他のデバイスでの通話」で有効なこのMac、macOSの許可確認を承諾したこと。確認できないものは、すべて無料の候補原因だ。
そのうえで何を優先するかを決める。通話が自分の机の上でだけ必要なら、VPNプロファイルからローカル通信を除外すれば通常は足り、トンネルの目的も弱めない。iPhoneが別の場所にあるときにも必要なら、リレーは適切な機能ではなく、キャリアの問題を先に考えることになる。