SSHトンネリングをSIP VOIP暗号化に使用できないのはなぜですか？
http://www.voip-info.org/wiki/index.php?page_id=2716 には、「SSHトンネリングはVoIPメディアパス暗号化の実行可能な方法ではないことに注意してください」と書かれています。安全でないVOIPプロトコル（通常のSIPなど）を使用している場合、（VPNではなく）SSHトンネリングをVOIP暗号化に使用できないのはなぜですか？
SSHプロトコルはTCP/IPスタックのTCP部分）上で実行されます。SIPまたは他のタイプのVoIPは、通常、UDPプロトコル上で実行されます。
TCPとUDPの大きな違いの1つは、TCP（ある程度））が各パケットの配信を保証することです。一方、UDPは保証しません。ファイアアンドフォーゲット。ネットワークに問題がある場合、その結果TCPは停止し、欠落した/破損したパケットを再送信しようとします。UDPを使用すると、パケットは単に失われます。
それをVOIPに適用すると、欠落しているUDPパケットは、発信者によって文字化けしたWordに変わります。欠落しているTCPパケットは、通話中に一貫性がなく、迷惑な遅延、文字化けした単語、およびその他の干渉になります。
VoIPやストリーミング音楽、特定の種類のストリーミングビデオ、その他のリアルタイム関連アプリケーションなど、一部のパケット損失が重要ではないアプリケーションでは、UDPは完全に受け入れられ、TCPは不要なオーバーヘッドを提供し、合併症。
SSHプロトコルは、SSH接続内で暗号化されたデータの整合性を確保するために各パケットが重要であるため、ロスレス接続を想定しています。
SSHトンネリングはVoIPメディアパス暗号化の実行可能な方法ではないことに注意してください。
強調鉱山。
メディアストリームは通常、 Session Description Protocol を使用したSIP呼び出し中にネゴシエートされ、多くの場合、 Real-time Transport Protocol を使用した双方向オーディオストリームとしてネゴシエートされます。
RTPのウィキペディアの記事から：
伝送制御プロトコル（TCP）は、RTPでの使用が標準化されていますが、RTPは適時性よりも信頼性を優先するため、通常はTCPアプリケーションでは使用されません。代わりに、RTP実装の大部分は、ユーザーデータグラムプロトコル（UDP）に基づいて構築されています。
UDPとTCPの違いに関する他の回答は当てはまりますが（特にSSH経由でUDPトンネルを試行する場合）、RTPほどSIPにとって重要ではありません。 SIPは、TCP（さらにはSCTP）上で完全に実行できます。ネットワークの遅延および/または再送信は、トランスポートプロトコル（TCP/SCTP）によって処理されるか、これらの機能がトランスポート層（UDP）で提供されない場合、SIPには独自の機能があります。再送信とタイムアウトのメカニズム。
ただし、SSH経由のSIPトンネリングを介したTCPのルーティングで問題が発生する可能性があります。これは、SIPがNATをトラバースするのが非常に簡単ではないのと同様の理由です。 SIPおよびSDP本体の多くのヘッダーには、関連するIPアドレスが含まれています。これは、トンネルで暗黙的に隠されている可能性があります。アプリケーション層ゲートウェイは通常、NATシナリオでこれを処理します。
実際、注意しないと、SIPをまったくトンネリングせずにSSH経由でRTPをトンネリングしてしまう可能性があります。
著者の意図と対象読者を推測することしかできないと思います（そして、5年以上前に書かれたことを覚えておいてください）。問題は、SSHがUDPではなくTCPストリームを処理するように設計されていることだと思います。
SSHを介したUDPのトンネリング への参照を見つけましたが、それはより複雑なハックのようです-おそらくVOIPネットワークにとって理想的なものではありません。同様に、一部のVPN（OpenVPNなど）はTCPトンネルを作成できますが、パケット損失に対する耐性が高いため、UDPトンネルが最も好まれると思います。
Chを見る a TCP vs UDPトンネルの特性 UDPトンネルが気にしないパケットを失うと、それをドロップし、カプセル化されたストリームを期待します（ TCP）またはアプリケーション（UDPの場合）がそれを処理する場合TCPトンネルはパケットを再送信しようとします。これは、接続のジッターを突然大幅に増加させる影響を与える可能性があります。特にエンドポイントが遠くにある場合、VOIP接続を非常に不幸にします。