要約

  • RFC 3960 の 180 Ringing は着信者への呼出しを示すが、インバンドの呼出音や案内が発信者へ届いた証明ではない。
  • 端末はパケットが来ない間だけローカル音を生成し、到着後は受信メディアへ切り替えられる。交渉、認証、再生、最終結果はそれぞれ独立した判定である。

呼出音は遠くの電話機から返ってくるように聞こえる。しかし SIP 端末では、その音を発信側が作っていることがある。着信側から「呼出中」という応答は届いたが、メディアはまだ来ていない。そこで端末がローカル音を流す。後から案内や特別な呼出音のパケットが届けば、端末は自分の音を止める。利用者には一続きでも、証拠の発行者は途中で変わる。

RFC 3960 は、最初の INVITE から最終応答までに交換される早期メディアを整理した。呼出音、待ち行列の案内、エラーメッセージ、対話的な入力などが対象になる。文書の核心は、SIP の進行表示とメディアの存在を同一視しなかった点にある。

POTS 型端末の例は三段階である。180 Ringing 前にはローカル呼出音を出さない。180 後、受信パケットがなければローカル音を出す。パケットがあればそれを再生し、ローカル音を止める。180 が示すのは着信者が呼び出されている状態であり、早期メディアセッションの状態にかかわらず、その状態なら UAS は応答を送るべきだとされる。

シグナリングだけでは判断できない。単純な UAS は信頼できる暫定応答を使わずに早期メディアを送り得る。別の UAS は、プリコンディション処理のために信頼できる暫定応答内で answer を返しても、すぐにはメディアを送らない。RFC 3262 の RSeq、RAck、PRACK は暫定応答を確実にするが、RTP の到着証明ではない。RFC 3312 の資源条件も、音が届いたという判定とは異なる。

経路も別である。SIP はサービスを提供する複数のプロキシを通り、メディアは遅延を減らす経路を選びやすい。パケットが、それを説明する SIP 応答より先に到着することがある。反対に 180 が先に届き、メディア接続の準備が続く場合もある。「早期メディアあり」という一つの標識では両方の競合を解けない。RFC 3960 は観測に基づき、まずローカルに進行を知らせ、実際のメディアが来たら譲る方法を示した。

パケット到着も最終判定ではない。中身が無音やコンフォートノイズだけかもしれない。RFC 3711 の SRTP は認証、完全性、リプレイ防止、必要に応じた暗号化を提供する。それでも復号・認証成功は、デコード、スピーカー出力、人が聞いたことを証明しない。180、交渉済みタプル、最初のパケット、最初の認証済み有用音声は別々に記録すべきである。

RFC 3264 は offer/answer を、RFC 3261 は SIP を定義した。パラメータの合意は互換性の証拠であって、トラフィックの証拠ではない。200 OK よりメディアが先行するため、UAC は最終応答前でも再生できなければならない。そうしなければ応答者の冒頭が欠ける。

フォーキングでは複数の早期ダイアログが生まれる。音声を全部混ぜれば混乱し、帯域が足りなければ一つを選ぶ必要がある。ゲートウェイモデルでは UAC が一枝を選び、残りをミュートすることがある。しかし後に 2xx を返すのがミュートされた枝なら、解除までメディアを送れずクリッピングが起きる。先に聞こえた枝が最終相手を決めるわけではない。

アプリケーションサーバーモデルは早期メディアと通常メディアを分離する。RFC 3959 は early-session disposition と option tag を定義した。UAC は早期 offer を拒否・ミュートしても、受諾後に使う通常セッションを損なわずに済む。ただし複数の早期セッションから何を提示するかは、なお端末の判断である。

Alert-Info は開始時刻を決めない。端末がローカル呼出音を出すと決めた場合に、どの音を使うか指定するだけである。

セキュリティ上、SDP のアドレスとポートは所有者を認証しない。攻撃者が推測してパケットを注入したり、悪意ある offer で第三者へ大量送信させたりできる。文書はセッション記述の保護、メディア認証、大量送信前の受信意思確認を論じる。また早期メディアが無料なら、200 OK を返さず双方向通信を続ける料金回避の誘因がある。一方で全面禁止は、受諾前に PIN を集める正当な IVR まで壊す。

この RFC が残したのは、呼出音の作り方より証拠の分離である。呼出中、ローカル音、到着ストリーム、人が聞いた結果は滑らかにつなげられるが、同じ事実にはならない。

RFC Editor の書誌情報と正誤表検索が文書記録を支える。関連仕様は RFC 3261、RFC 3262、RFC 3264、RFC 3959、RFC 3312、RFC 3711である。