RFC 5626-2009
セッション開始プロトコル (SIP) でのクライアント開始接続の管理 (更新: 3261 3327)

規格番号

RFC 5626-2009

制定年

2009

出版団体

IETF - Internet Engineering Task Force

最新版

RFC 5626-2009

範囲

「はじめに SIP [RFC3261] 導入環境には、ユーザー エージェント (UA) がレジストラまたはプロキシへの接続を形成できるものの、UA への逆方向の接続が不可能な環境が数多くあります。 これは、いくつかの理由で発生する可能性があります。 @ しかし、最も可能性が高いのは、SIP UA とプロキシの間にある NAT またはファイアウォールです。 そのようなデバイスの多くは、送信接続のみを許可します。 この仕様により、そのようなファイアウォールまたは NAT の背後にある SIP ユーザー エージェントが、登録またはプロキシに関連付けられた受信トラフィックを受信できるようになります。 ほとんどの IP 電話やパーソナル コンピュータは、Dynamic Host Configuration Protocol (DHCP) [RFC2131] などのプロトコルを介してネットワーク構成を動的に取得します。 これらのシステムは通常、ドメイン ネーム システム (DNS) で有用な名前を持っていません。 [RFC1035]@ そして、[RFC3261] で要求されているように、証明書の subjectAltName での使用に適した、長期的に安定した DNS 名を持つことはほとんどありません@。 ただし、これらのシステムは依然としてトランスポート層セキュリティ (TLS) として機能できます。 ) [RFC5246] クライアントは、サーバー証明書で認証するプロキシまたはレジストラへのアウトバウンド接続を形成します。 サーバーは、その TLS 接続上で (RFC 3261 のセクション 22 で定義されている) ダイジェスト チャレンジの共有秘密を使用して UA を認証できます。 この仕様により、TLS 接続を開始する必要がある SIP ユーザー エージェントが、自身が開始する登録またはダイアログに関連付けられた受信トラフィックを受信できるようになります。 この仕様の重要な考え方は、UA が REGISTER リクエストまたはダイアログ形成リクエストを送信するとき、プロキシは後でこの同じネットワーク「フロー」を使用できるということです。 これが TCP 接続の UDP データグラムの双方向ストリームであるかどうかは関係ありません。 @ または別のトランスポート プロトコルの類似の概念 -- 登録またはダイアログのコンテキストでこの UA に送信する必要がある受信リクエストを転送します。 UA が受信リクエストを受信するには、UA はサーバーに接続する必要があります。 サーバーは UA@ に接続できないため、UA はフローが常にアクティブであることを確認する必要があります。 これには、フローが失敗したときを UA が検出する必要があります。 このような検出には時間がかかり、受信リクエストを逃す機会が残るため、このメカニズムにより、UA は複数のフローに同時に登録できます。 この仕様では、2 つのキープアライブ スキームも定義します。 キープアライブ メカニズムは、NAT バインディングを最新の状態に保ち、フローが失敗したときを UA が検出できるようにするために使用されます。

RFC 5626-2009 発売履歴

• 2009 RFC 5626-2009 セッション開始プロトコル (SIP) でのクライアント開始接続の管理 (更新: 3261 3327)