[要約] RFC 7584は、SIPバックトゥバックユーザーエージェント（B2BUA）のためのSTUNメッセージの処理に関するガイドラインです。その目的は、B2BUAがSTUNメッセージを適切に処理し、NATトラバーサルをサポートすることです。
Internet Engineering Task Force (IETF) R. Ravindranath
Request for Comments: 7584 T. Reddy
Category: Standards Track G. Salgueiro
ISSN: 2070-1721 Cisco
July 2015
Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs)
NATのセッショントラバーサルユーティリティ（STUN）SIPバックツーバックユーザーエージェント（B2BUA）のメッセージ処理
Abstract
概要
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) are often designed to be on the media path rather than just intercepting signaling. This means that B2BUAs often act on the media path leading to separate media legs that the B2BUA correlates and bridges together. When acting on the media path, B2BUAs are likely to receive Session Traversal Utilities for NAT (STUN) packets as part of Interactive Connectivity Establishment (ICE) processing.
セッション開始プロトコル（SIP）バックツーバックユーザーエージェント（B2BUA）は、シグナリングを傍受するだけでなく、メディアパス上にあるように設計されることがよくあります。これは、B2BUAがメディアパスに作用して、B2BUAが相互に関連付けてブリッジする個別のメディアレッグにつながることがよくあることを意味します。メディアパスで動作する場合、B2BUAは、対話型接続確立（ICE）処理の一部として、NAT（STUN）パケットのセッショントラバーサルユーティリティを受信する可能性があります。
This document defines behavior for a B2BUA performing ICE processing. The goal of this document is to ensure that B2BUAs properly handle SIP messages that carry ICE semantics in Session Description Protocol (SDP) and STUN messages received as part of the ICE procedures for NAT and Firewall traversal of multimedia sessions.
このドキュメントでは、ICE処理を実行するB2BUAの動作を定義します。このドキュメントの目的は、マルチメディアセッションのNATおよびファイアウォールトラバーサルのICE手順の一部として受信したセッション記述プロトコル（SDP）のICEセマンティクスを含むSIPメッセージとSTUNメッセージをB2BUAが適切に処理できるようにすることです。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7584.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7584で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SDP-Modifying Signaling-only B2BUA . . . . . . . . . . . . . 5
4. Media Plane B2BUAs . . . . . . . . . . . . . . . . . . . . . 5
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Mandatory ICE Termination with B2BUA . . . . . . . . . . 6
4.3. Optional ICE Termination with B2BUA . . . . . . . . . . . 9
4.4. STUN Handling in B2BUA with Forked Signaling . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
In many SIP deployments, SIP entities exist in the SIP signaling and media path between the originating and final terminating endpoints, which go beyond the definition of a traditional SIP proxy. These SIP entities, commonly known as B2BUAs, are described in [RFC7092] and often perform functions not defined in Standards Track RFCs.
多くのSIP展開では、SIPエンティティは、SIPシグナリングと、従来のSIPプロキシの定義を超える、発信エンドポイントと最終終端エンドポイント間のメディアパスに存在します。これらのSIPエンティティは、一般にB2BUAとして知られ、[RFC7092]で説明されており、Standards Track RFCで定義されていない機能を実行することがよくあります。
SIP [RFC3261] and other session control protocols that try to use a direct path for media are typically difficult to use across Network Address Translators (NATs). These protocols use IP addresses and transport port numbers encoded in the signaling, such as SDP [RFC4566] and, in the case of SIP, various header fields. Such addresses and ports are unreachable if any peers are separated by NATs.
メディアの直接パスを使用しようとするSIP [RFC3261]およびその他のセッション制御プロトコルは、通常、ネットワークアドレス変換（NAT）全体で使用することは困難です。これらのプロトコルは、SDP [RFC4566]などのシグナリングでエンコードされたIPアドレスとトランスポートポート番号を使用し、SIPの場合はさまざまなヘッダーフィールドを使用します。ピアがNATによって分離されている場合、そのようなアドレスとポートには到達できません。
Mechanisms such as STUN [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and ICE [RFC5245] did not exist when protocols like SIP began to be deployed. Some mechanisms, such as the early versions of STUN, started appearing, but they were unreliable and suffered a number of issues typical for UNilateral Self-Address Fixing (UNSAF) as described in [RFC3424]. For these reasons, B2BUAs are being used by SIP domains for SIP and media-related purposes. These B2BUAs use proprietary mechanisms to enable SIP devices behind NATs to communicate across the NAT.
STUN [RFC5389]、NAT周りのリレーを使用したトラバーサル（TURN）[RFC5766]、ICE [RFC5245]などのメカニズムは、SIPなどのプロトコルが導入され始めたときには存在しませんでした。 STUNの初期バージョンなどの一部のメカニズムが登場し始めましたが、信頼性が低く、[RFC3424]で説明されているように、UNilateral Self-Address Fixing（UNSAF）に典型的な多くの問題が発生しました。これらの理由により、B2BUAはSIPおよびメディア関連の目的でSIPドメインによって使用されています。これらのB2BUAは、独自のメカニズムを使用して、NATの背後にあるSIPデバイスがNATを介して通信できるようにします。
[RFC7362] describes how B2BUAs can perform Hosted NAT Traversal (HNT) in certain deployments. Section 5 of [RFC7362] describes some of the issues with Session Border Controllers (SBCs) implementing HNT and offers some mitigation strategies. The most commonly used approach to solve these issues is "restricted-latching", defined in Section 5 of [RFC7362], whereby the B2BUA will not latch to any packets from a source public IP address other than the one the SIP User Agent (UA) uses for SIP signaling. However, this is susceptible to attacks where an attacker who is able to see the source IP address of the SIP UA may generate packets using the same IP address. There are other threats described in Section 5 of [RFC7362] for which Secure Real-time Transport Protocol (SRTP) [RFC3711] can be used as a solution. However, this would require the B2BUAs to terminate and reoriginate SRTP, which is not always desirable.
[RFC7362]では、特定の展開でB2BUAがホスト型NATトラバーサル（HNT）を実行する方法について説明しています。 [RFC7362]のセクション5は、HNTを実装するセッションボーダーコントローラー（SBC）に関するいくつかの問題を説明し、いくつかの緩和戦略を提供します。これらの問題を解決するために最も一般的に使用されるアプローチは、[RFC7362]のセクション5で定義されている「制限付きラッチ」です。これにより、B2BUAは、SIPユーザーエージェント（UA）以外のソースパブリックIPアドレスからのパケットにラッチしません。 ）SIPシグナリングに使用します。ただし、これは、SIP UAのソースIPアドレスを見ることができる攻撃者が同じIPアドレスを使用してパケットを生成する可能性がある攻撃に対して脆弱です。 [RFC7362]のセクション5で説明されている他の脅威については、Secure Real-time Transport Protocol（SRTP）[RFC3711]をソリューションとして使用できます。ただし、これはSRTPを終了して再発信するためにB2BUAを必要とするため、常に望ましいとは限りません。
This document describes proper behavior of B2BUAs performing ICE processing. This includes defining consistent handling of SIP messages carrying ICE semantics in SDP and STUN messages received as part of the ICE procedures performed on the media path for NAT and Firewall traversal of multimedia sessions.
このドキュメントでは、ICE処理を実行するB2BUAの適切な動作について説明します。これには、マルチメディアセッションのNATおよびファイアウォールトラバーサルのメディアパスで実行されるICE手順の一部として受信されたSDPおよびSTUNメッセージでICEセマンティクスを運ぶSIPメッセージの一貫した処理の定義が含まれます。
A B2BUA can use ICE [RFC5245], which provides authentication tokens (conveyed in the ice-ufrag and ice-pwd attributes) that allow the identity of a peer to be confirmed before engaging in media exchange. This can solve some of the security concerns with HNT solution. Further, ICE has other benefits like selecting an address when more than one address is available (e.g., a dual-stack environment where the host can have both IPv4 and IPv6 addresses), verifying that a path works before connecting the call, etc. For these reasons, endpoints often use ICE to pick a candidate pair for media traffic between two agents.
B2BUAはICE [RFC5245]を使用できます。これは、メディア交換に従事する前にピアのIDを確認できる認証トークン（ice-ufragおよびice-pwd属性で伝達される）を提供します。これにより、HNTソリューションのセキュリティ上の懸念の一部を解決できます。さらに、ICEには、複数のアドレスが利用可能な場合にアドレスを選択する（ホストがIPv4アドレスとIPv6アドレスの両方を持つことができるデュアルスタック環境など）、通話を接続する前にパスが機能することを確認するなど、他の利点もあります。これらの理由により、エンドポイントは多くの場合、ICEを使用して、2つのエージェント間のメディアトラフィックの候補ペアを選択します。
B2BUAs often operate on the media path and have the ability to modify SIP headers and SDP bodies as part of their normal operation. Such entities, when present on the media path, are likely to take an active role in the session signaling depending on their level of activity on the media path. For example, some B2BUAs modify portions of the SDP body (e.g., IP address, port) and subsequently modify the media packet headers as well. Section 18.6 of ICE [RFC5245] explains two different behaviors when B2BUAs are present. Some B2BUAs are likely to remove all the SDP ICE attributes before sending the SDP across to the other side. Consequently, the call will appear to both endpoints as though the other side doesn't support ICE. There are other types of B2BUAs that pass the ICE attributes without modification, yet modify the default destination for media contained in the "m=" and "c=" lines and the RTCP attribute (defined in [RFC3605]). This will be detected as an ice-mismatch, and ICE processing will be aborted for the session. The session may continue if the endpoints are able to reach each other over the default candidate (sent in "m=" and "c=" lines).
B2BUAはメディアパスで動作することが多く、通常の動作の一部としてSIPヘッダーとSDP本体を変更する機能があります。そのようなエンティティは、メディアパス上に存在する場合、メディアパス上のアクティビティのレベルに応じて、セッションシグナリングでアクティブな役割を果たす可能性があります。たとえば、一部のB2BUAは、SDPボディの一部（IPアドレス、ポートなど）を変更し、続いてメディアパケットヘッダーも変更します。 ICE [RFC5245]のセクション18.6では、B2BUAが存在する場合の2つの異なる動作について説明しています。一部のB2BUAは、SDPを反対側に送信する前に、すべてのSDP ICE属性を削除する可能性があります。その結果、反対側がICEをサポートしていないかのように、コールは両方のエンドポイントに表示されます。 ICE属性を変更せずに渡す他のタイプのB2BUAがありますが、 "m ="および "c ="行に含まれるメディアのデフォルトの宛先とRTCP属性（[RFC3605]で定義）を変更します。これは氷の不一致として検出され、ICE処理はセッションに対して中止されます。エンドポイントがデフォルトの候補（「m =」行と「c =」行で送信）を介して相互に到達できる場合、セッションは継続する可能性があります。
Section 3.1.3 of [RFC7092] defines a SDP-Modifying Signaling-only B2BUA that operates in the signaling plane only and is not in the media path, but it does modify SDP bodies and is thus aware of and understands SDP syntax and semantics. Such B2BUA MUST follow the behavior mentioned in Section 3.
[RFC7092]のセクション3.1.3は、シグナリングプレーンでのみ動作し、メディアパスにはないSDP変更シグナリングのみのB2BUAを定義していますが、SDP本体を変更するため、SDP構文とセマンティクスを認識して理解しています。そのようなB2BUAは、セクション3で述べた動作に従う必要があります。
Section 3.2 of [RFC7092] describes three different categories of B2BUAs that operate on both the signaling (SIP and SDP) and media planes according to the level of involvement and active participation in the media plane:
[RFC7092]のセクション3.2では、メディアプレーンへの関与とアクティブな参加のレベルに応じて、シグナリング（SIPおよびSDP）とメディアプレーンの両方で動作するB2BUAの3つの異なるカテゴリについて説明します。
o A B2BUA that acts as a simple media relay. It is effectively unaware of anything that is transported and only modifies the transport header (could be UDP/IP) of the media packets.
o 単純なメディアリレーとして機能するB2BUA。トランスポートされるものを事実上認識せず、メディアパケットのトランスポートヘッダー（UDP / IPの場合もある）のみを変更します。
o A B2BUA that performs a media-aware role. It inspects and potentially modifies RTP or RTP Control Protocol (RTCP) headers; but it does not modify the payload of RTP/RTCP.
o メディア対応の役割を実行するB2BUA。 RTPまたはRTP制御プロトコル（RTCP）ヘッダーを検査し、場合によっては変更します。ただし、RTP / RTCPのペイロードは変更されません。
o A B2BUA that performs a media-termination role and operates at the media payload layer, such as RTP/RTCP payload (e.g., a transcoder).
o メディアターミネーションの役割を実行し、RTP / RTCPペイロード（トランスコーダーなど）などのメディアペイロードレイヤーで動作するB2BUA。
When B2BUAs that operate on the media plane (media relay, media aware, or media termination) are involved in a session between two endpoints performing ICE, then it MUST follow the behavior described in Section 4.
メディアプレーン（メディアリレー、メディア認識、またはメディアターミネーション）で動作するB2BUAが、ICEを実行する2つのエンドポイント間のセッションに関与する場合、セクション4で説明されている動作に従う必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
All of the pertinent B2BUA terminology and taxonomy used in this document is defined in [RFC7092].
このドキュメントで使用されている関連するすべてのB2BUA用語と分類法は、[RFC7092]で定義されています。
NATs are widely used in the Internet by consumers and organizations. Although specific NAT behaviors vary, this document uses the term "NAT", which maps to NAT and Network Address Port Translation (NAPT) terms from [RFC3022], for devices that map any IPv4 or IPv6 address and transport port number to another IPv4 or IPv6 address and transport port number. This includes consumer NATs, Firewall-NATs, IPv4-IPv6 NATs, Carrier-Grade NATs (CGNs) [RFC6888], etc.
NATは消費者や組織によってインターネットで広く使用されています。特定のNAT動作は異なりますが、このドキュメントでは、「RFC3022」のNATおよびネットワークアドレスポート変換（NAPT）の用語にマッピングされる「NAT」という用語を使用して、IPv4またはIPv6アドレスとトランスポートポート番号を別のIPv4またはIPv6アドレスとトランスポートポート番号。これには、コンシューマNAT、ファイアウォールNAT、IPv4-IPv6 NAT、キャリアグレードNAT（CGN）[RFC6888]などが含まれます。
An SDP-Modifying Signaling-only B2BUA is one that operates in the signaling plane only and is not in the media path, but it modifies SDP bodies as described in Section 3.1.3 of [RFC7092]. Such B2BUAs MUST NOT change the IP address in the "c=" line, the port in the "m=" line, and the ICE semantics of SDP, as doing so can cause an ice-mismatch.
SDP-Modifying Signaling-only B2BUAは、シグナリングプレーンでのみ動作し、メディアパスではありませんが、[RFC7092]のセクション3.1.3で説明されているようにSDP本体を変更します。そのようなB2BUAは、「c =」行のIPアドレス、「m =」行のポート、およびSDPのICEセマンティクスを変更してはなりません。変更すると、氷の不一致が発生する可能性があるためです。
When one or both of the endpoints are behind a NAT, and there is a B2BUA between the endpoints, the B2BUAs MUST support ICE or at a minimum support ICE lite functionality as described in [RFC5245]. Such B2BUAs MUST use the mechanism described in Section 2.2 of [RFC5245] to demultiplex STUN packets that arrive on the RTP/RTCP port.
エンドポイントの一方または両方がNATの背後にあり、エンドポイント間にB2BUAがある場合、B2BUAはICEをサポートするか、[RFC5245]で説明されているICE lite機能を最低限サポートする必要があります。このようなB2BUAは、[RFC5245]のセクション2.2で説明されているメカニズムを使用して、RTP / RTCPポートに到着するSTUNパケットを逆多重化する必要があります。
The subsequent sections describe the behavior B2BUAs MUST follow for handling ICE messages. A B2BUA can terminate ICE and thus have two ICE contexts with either endpoint. The reason for ICE termination could be due to the need for B2BUA to be in the media path (e.g., address hiding for privacy, interworking between ICE to no-ICE, etc.). A B2BUA can also be in optional ICE termination mode and passes across the candidate list and STUN short-term credentials (ice-ufrag and ice-pwd attributes) from one endpoint to the other side after adding its own candidates. A B2BUA can be in optional ICE termination mode when it does not have a need to be on the media path. The below sections describe the behaviors for these two cases.
以降のセクションでは、ICEメッセージを処理するためにB2BUAが従わなければならない動作について説明します。 B2BUAはICEを終了できるため、どちらのエンドポイントにも2つのICEコンテキストがあります。 ICEが終了する理由は、B2BUAがメディアパス内にある必要があるためである可能性があります（プライバシー保護のためのアドレス非表示、ICEからICEへのインターワーキングなど）。 B2BUAはオプションのICE終了モードにすることもでき、独自の候補を追加した後、一方のエンドポイントから他方の側に候補リストとSTUN短期資格情報（ice-ufragおよびice-pwd属性）を通過します。 B2BUAは、メディアパス上にある必要がない場合、オプションのICE終了モードにすることができます。以下のセクションでは、これら2つのケースの動作について説明します。
A B2BUA that wishes to always be in the media path follows these steps:
常にメディアパスに存在することを望むB2BUAは、次の手順に従います。
o When a B2BUA sends out the SDP, it MUST advertise support for ICE and MAY include B2BUA's candidates of different types for each component of each media stream.
o B2BUAがSDPを送信する場合、B2BUAはICEのサポートをアドバタイズする必要があり、各メディアストリームのコンポーネントごとに異なるタイプのB2BUAの候補を含めることができます（MAY）。
o If the B2BUA is in ICE lite mode as described in Section 2.7 of [RFC5245], then it MUST send an a=ice-lite attribute and MUST include B2BUA host candidates for each component of each media stream.
o [RFC5245]のセクション2.7で説明されているようにB2BUAがICEライトモードの場合、a = ice-lite属性を送信し、各メディアストリームの各コンポーネントのB2BUAホスト候補を含める必要があります。
o If the B2BUA supports full ICE, then it MAY include B2BUA's candidates of different types for each component of each media stream.
o B2BUAが完全なICEをサポートしている場合は、各メディアストリームのコンポーネントごとに異なるタイプのB2BUAの候補を含めることができます（MAY）。
o The B2BUA MUST generate new username and password values for ice-ufrag and ice-pwd attributes when it sends out the SDP and MUST NOT propagate the ufrag password values it received in the incoming SDP. This ensures that the short-term credentials used for both the legs are different. The short-term credentials include authentication tokens (conveyed in the ice-ufrag and ice-pwd attributes), which the B2BUA can use to verify the identity of the peer. The B2BUA terminates the ICE messages on each leg and does not propagate them.
o B2BUAは、SDPを送信するときに、ice-ufragおよびice-pwd属性の新しいユーザー名とパスワードの値を生成する必要があり、着信SDPで受信したufragパスワード値を伝播してはなりません。これにより、両方のレッグに使用される短期的な認証情報が確実に異なります。短期的な認証情報には、B2BUAがピアのIDを確認するために使用できる認証トークン（ice-ufragおよびice-pwd属性で伝達される）が含まれています。 B2BUAは各レッグのICEメッセージを終了し、伝搬しません。
o The B2BUA MUST NOT propagate the candidate list received in the incoming SDP to the outbound SDP and instead only advertise its candidate list. The B2BUA MUST also add its default candidate in the "c=" line (IP address) and "m=" line (port). In this way, the B2BUA will be always in the media path.
o B2BUAは、着信SDPで受信した候補リストを発信SDPに伝播してはならず、代わりにその候補リストのみをアドバタイズする必要があります。 B2BUAは、「c =」行（IPアドレス）および「m =」行（ポート）にもデフォルトの候補を追加する必要があります。このように、B2BUAは常にメディアパスにあります。
o Depending on whether the B2BUA supports ICE lite or full ICE, it implements the appropriate procedures mentioned in [RFC5245] for ICE connectivity checks.
o B2BUAがICEライトをサポートするかフルICEをサポートするかに応じて、ICEの接続性チェックについて[RFC5245]で説明されている適切な手順を実装します。
+-------+ +-------------------+ +-----+
| Alice | | Media Plane B2BUA | | Bob |
+-------+ +-------------------+ +-----+
|(1) INVITE |(3) INVITE |
| a=ice-ufrag1 | a=ice-ufrag2 |
| a=ice-pwd1 | a=ice-pwd2 |
| (Alice's IP, port) | (B2BUA's IP, port) |
| (Alice's candidate list)| (B2BUA's candidate list)|
|------------------------>|-------------------------->|
| | |
|(2) 100 trying | |
|<------------------------| |
| |(4) 100 trying |
| |<--------------------------|
| | |
| |(5) 200 OK |
| | a=ice-ufrag3 |
| | a=ice-pwd3 |
| | (Bob's IP, port) |
| | (Bob's candidate list) |
| |<--------------------------|
|(6) 200 OK | |
| a=ice-ufrag4 |-----------ACK------------>|
| a=ice-pwd4 | (7) |
| (B2BUA's IP, port) | |
|(B2BUA's candidate list1)| |
|<------------------------| |
| | |
|--------ACK------------->| |
| (8) | |
| | |
|<----ICE Connectivity 1->| |
| checks+conclusion |<-----ICE Connectivity 2-->|
| (9) | checks+conclusion |
| | (10) |
| | |
|<-------Media packets--->|<----Media packets-------->|
| (11) | (12) |
| | |
|<---ICE keepalives 1---->| |
| (13) |<----ICE keepalives 2----->|
(13)
Figure 1: INVITE with SDP Having ICE and with a Media Plane B2BUA Terminating ICE
図1：SDPにICEがあり、メディアプレーンB2BUAがICEを終了しているINVITE
The above figure shows an example call flow with two endpoints, Alice and Bob, using ICE processing, and a B2BUA handing STUN messages from both the endpoints. For the sake of brevity, the entire list of ICE SDP attributes are not shown. Also, the STUN messages exchanged as part of ICE connectivity checks are not shown. Key steps to note from the call flow are:
上の図は、ICE処理を使用する2つのエンドポイントAliceとBobのコールフローの例と、両方のエンドポイントからのSTUNメッセージを処理するB2BUAを示しています。簡潔にするため、ICE SDP属性のリスト全体は示していません。また、ICE接続性チェックの一部として交換されるSTUNメッセージは表示されません。コールフローからメモする主な手順は次のとおりです。
o Alice sends an INVITE with SDP having ICE candidates.
o アリスは、ICE候補を持つSDPを使用してINVITEを送信します。
o The B2BUA modifies the received SDP from Alice by removing the received candidate list, gathering its own candidates, and generating new username and password values for ice-ufrag and ice-pwd attributes. The B2BUA also changes the "c=" line and "m=" line to have its default candidate and forwards the INVITE (Step 3) to Bob.
o B2BUAは、受信した候補リストを削除し、独自の候補を収集し、ice-ufragおよびice-pwd属性の新しいユーザー名とパスワードの値を生成することにより、Aliceから受信したSDPを変更します。 B2BUAは、「c =」行と「m =」行をデフォルトの候補に変更し、INVITE（ステップ3）をBobに転送します。
o Bob responds (Step 5) to the INVITE with his own list of candidates.
o ボブは自分の候補者リストでINVITEに応答します（ステップ5）。
o The B2BUA responds to the INVITE from Alice with SDP having a B2BUA candidate list. The B2BUA generates new username and password values for ice-ufrag and ice-pwd attributes in the 200 OK response (Step 6).
o B2BUAは、B2BUA候補リストを持つSDPでアリスからのINVITEに応答します。 B2BUAは、200 OK応答でIce-ufragおよびice-pwd属性の新しいユーザー名とパスワードの値を生成します（ステップ6）。
o ICE Connectivity checks happen between Alice and the B2BUA in Step 9. Depending on whether the B2BUA supports ICE or ICE lite, it will follow the appropriate procedures mentioned in [RFC5245]. ICE Connectivity checks also happen between Bob and the B2BUA in Step 10. Steps 9 and 10 happen in parallel. The B2BUA always terminates the ICE messages on each leg and has two independent ICE contexts running.
o ICE接続性チェックは、手順9でアリスとB2BUAの間で行われます。B2BUAがICEをサポートしているか、ICE liteをサポートしているかに応じて、[RFC5245]で説明されている適切な手順に従います。 ICE接続性チェックは、ステップ10でボブとB2BUAの間でも行われます。ステップ9と10は並行して行われます。 B2BUAは常に各レッグのICEメッセージを終了し、2つの独立したICEコンテキストが実行されています。
o Media flows between Alice and Bob via B2BUA (Steps 11 and 12).
o メディアはB2BUAを介してアリスとボブの間を流れます（ステップ11と12）。
o STUN keepalives would be used between Alice and B2BUA (Step 13) and between Bob and B2BUA (Step 14) to keep NAT and Firewall bindings alive.
o STUNキープアライブは、AliceとB2BUAの間（ステップ13）およびBobとB2BUAの間（ステップ14）で使用され、NATとファイアウォールのバインディングを維持します。
Since there are two independent ICE contexts on either side of the B2BUA, it is possible that ICE checks will conclude on one side before concluding on the other side. This could result in an ongoing media session for one end while the other is still being set up. Any such media received by the B2BUA would continue to be sent to the other side on the default candidate address (that was sent in "c=" line).
B2BUAのいずれかの側に2つの独立したICEコンテキストがあるため、ICEチェックが一方の側で完了してから、他方の側で完了する可能性があります。これにより、一方の端でメディアセッションが継続し、もう一方の端がまだセットアップされている可能性があります。 B2BUAによって受信されたそのようなメディアは、デフォルトの候補アドレス（「c =」行で送信された）で相手側に送信され続けます。
A B2BUA willing to be in the media path only for NAT traversal, but that does not otherwise require to be in the media path, can do the following steps mentioned in this section.
B2BUAは、NATトラバーサルの場合のみメディアパスに存在することを希望しますが、それ以外の場合はメディアパスに存在する必要はありません。このセクションで説明する次の手順を実行できます。
o When a B2BUA receives an incoming SDP with ICE semantics, it copies the received candidate list and appends its own candidate list in the outgoing SDP. The B2BUA also copies the ufrag/ password values it received in the incoming SDP to the outgoing SDP and then sends out the SDP.
o B2BUAがICEセマンティクスで着信SDPを受信すると、受信した候補リストをコピーし、発信SDPに独自の候補リストを追加します。 B2BUAはまた、着信SDPで受信したufrag /パスワード値を発信SDPにコピーしてから、SDPを送信します。
o The B2BUA's candidates MAY have lower priority than the candidates provided by the endpoint, this way the endpoint and remote peer candidate pairs are tested first before trying candidate pairs with B2BUA's candidates.
o B2BUAの候補は、エンドポイントによって提供される候補よりも優先度が低い場合があります。このようにして、B2BUAの候補との候補ペアを試す前に、エンドポイントとリモートピアの候補ペアが最初にテストされます。
o After offer/answer is complete, the endpoints will have both the B2BUAs and remote peer candidates. It will then use ICE procedures described in Section 8 of [RFC5245] to nominate a candidate pair for sending and receiving media streams.
o オファー/アンサーが完了すると、エンドポイントにはB2BUAとリモートピア候補の両方が含まれます。次に、[RFC5245]のセクション8で説明されているICE手順を使用して、メディアストリームを送受信するための候補ペアを指定します。
o With this approach, the B2BUA will be in the media path only if the ICE checks between all the candidate pairs formed from both the endpoints fail.
o このアプローチでは、両方のエンドポイントから形成されたすべての候補ペア間のICEチェックが失敗した場合にのみ、B2BUAがメディアパスに配置されます。
+-------+ +-------------------+ +-----+
| Alice | | Media Plane B2BUA | | Bob |
+-------+ +-------------------+ +-----+
|(1) INVITE |(3) INVITE |
| a=ice-ufrag1 | a=ice-ufrag1 |
| a=ice-pwd1 | a=ice-pwd1 |
| (Alice's IP, port) | (Alice's IP, port) |
|(Alice's candidate list) | (Alice's candidate list + |
| | B2BUA's candidate list1) |
|------------------------>|-------------------------->|
| | |
|(2) 100 trying | |
|<------------------------| |
| |(4) 100 trying |
| |<--------------------------|
| | |
| |(5) 200 OK |
| | a=ice-ufrag2 |
| | a=ice-pwd2 |
| | (Bob's IP, port) |
| | (Bob's candidate list) |
| |<--------------------------|
|(6) 200 OK | |
| a=ice-ufrag2 |-----------ACK------------>|
| a=ice-pwd2 | (7) |
| (Bob's IP,port) | |
|(B2BUA's candidate list2 | |
| + Bob's candidate list) | |
|<------------------------| |
| | |
|----------ACK----------->| |
| (8) | |
| | |
|<----ICE Connectivity 1 (9)------------------------->|
| | |
|<----ICE Connectivity 2->| |
| checks+conclusion |<-----ICE Connectivity 2-->|
| (10) | checks+conclusion |
| | (11) |
| | |
|<-------------------Media packets------------------->|
| (12) |
| | |
|<------------------ICE keepalives------------------->|
(13)
Figure 2: INVITE with SDP Having ICE and with a Media Plane B2BUA in Optional ICE Termination Mode
図2：ICEを備えたSDPと、オプションのICE終了モードのメディアプレーンB2BUAを備えたINVITE
The above figure shows a sample call flow with two endpoints, Alice and Bob, doing ICE, and a B2BUA handing STUN messages from both the endpoints. For the sake of brevity, the entire ICE SDP attributes are not shown. Also, the STUN messages exchanged as part of the ICE connectivity checks are not shown. Key steps to note from the call flow are:
上の図は、ICEを実行する2つのエンドポイントAliceとBobのサンプルコールフローと、両方のエンドポイントからのSTUNメッセージを処理するB2BUAを示しています。簡潔にするため、ICE SDP属性全体は示していません。また、ICE接続性チェックの一部として交換されるSTUNメッセージは表示されません。コールフローからメモする主な手順は次のとおりです。
o Alice sends an INVITE with an SDP having its own candidate list.
o アリスは、独自の候補リストを持つSDPでINVITEを送信します。
o The B2BUA propagates the received candidate list in incoming SDP from Alice after adding its own candidate list. The B2BUA also propagates the received ice-ufrag and ice-pwd attributes from Alice in the INVITE (Step 3) to Bob. In this example, the B2BUA does not modify the default candidate sent in the "c=" line and "m=" line and retains the values sent originally from Alice. If B2BUA wants to be in the media path when ICE connectivity checks between endpoints fails or one of the endpoints does not support ICE, then it overwrites its candidate address and port as a default candidate in the "m=" and "c=" lines.
o B2BUAは、独自の候補リストを追加した後、受信した候補リストをAliceからの着信SDPに伝播します。 B2BUAは、受信したice-ufrag属性とice-pwd属性をINVITEのAlice（ステップ3）からBobに伝搬します。この例では、B2BUAは「c =」行と「m =」行で送信されたデフォルトの候補を変更せず、Aliceから最初に送信された値を保持します。エンドポイント間のICE接続チェックが失敗したとき、またはエンドポイントの1つがICEをサポートしていないときにB2BUAがメディアパスにあることを希望する場合、B2BUAは「m =」および「c =」行のデフォルト候補として候補アドレスおよびポートを上書きします。 。
o Bob responds (Step 5) to the INVITE with his own list of candidates.
o ボブは自分の候補者リストでINVITEに応答します（ステップ5）。
o The B2BUA responds to the INVITE from Alice with an SDP having a B2BUA's candidate list and the candidate list received from Bob. The B2BUA would also propagate the received ice-ufrag and ice-pwd attributes from Bob in (Step 5) to Alice in the 200 OK response (Step 6).
o B2BUAは、B2BUAの候補リストとボブから受信した候補リストを持つSDPでアリスからのINVITEに応答します。 B2BUAは、受信したice-ufrag属性とice-pwd属性をBob in（ステップ5）からAliceに200 OK応答（ステップ6）で伝搬します。
o ICE Connectivity checks happen between Alice and Bob in (Step 9). ICE Connectivity checks also happen between Alice and the B2BUA and Bob and the B2BUA as shown in Steps 10 and 11. Steps 9, 10, and 11 happen in parallel. In this example, Alice and Bob conclude ICE with a candidate pair that enables them to send media directly.
o ICE接続性チェックは、（ステップ9）でアリスとボブの間で行われます。手順10と11に示すように、ICE接続性チェックは、AliceとB2BUA、BobとB2BUAの間でも行われます。手順9、10、11は並行して行われます。この例では、アリスとボブは、メディアを直接送信できるようにする候補ペアを使用してICEを締結します。
o Media flows between Alice and Bob in Step 12.
o メディアは、ステップ12でアリスとボブの間を流れます。
Because of forking, a B2BUA might receive multiple answers for a single outbound INVITE. When this occurs, the B2BUA SHOULD follow Sections 3.2 or 3.3 for all of those received answers.
フォーキングが原因で、B2BUAは単一のアウトバウンドINVITEに対して複数の応答を受け取る場合があります。これが発生した場合、B2BUAは受け取ったすべての回答についてセクション3.2または3.3に従う必要があります（SHOULD）。
As described in Section 2.5 of [RFC5245], ICE uses the STUN short-term credential mechanism for authentication and message integrity. STUN connectivity checks include the MESSAGE-INTEGRITY attribute that contains HMAC-SHA1 of the STUN message, and the Hashed Message Authentication Code (HMAC) is computed using the key exchanged in the signaling channel. The signaling channel between the endpoints and B2BUA MUST be encrypted so that the key is not visible to eavesdroppers, otherwise the security benefits of short-term authentication would be lost.
[RFC5245]のセクション2.5で説明されているように、ICEは認証とメッセージの整合性のためにSTUN短期資格情報メカニズムを使用します。 STUN接続チェックには、STUNメッセージのHMAC-SHA1を含むMESSAGE-INTEGRITY属性が含まれ、ハッシュチャネルメッセージ認証コード（HMAC）は、シグナリングチャネルで交換されるキーを使用して計算されます。エンドポイントとB2BUAの間のシグナリングチャネルは、キーが盗聴者に見えないように暗号化する必要があります。そうしないと、短期認証のセキュリティ上の利点が失われます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004、<http://www.rfc-editor.org/info/rfc3711>。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、DOI 10.17487 / RFC5245、2010年4月、<http：// www .rfc-editor.org / info / rfc5245>。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<http：// www.rfc-editor.org/info/rfc5389>。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <http://www.rfc-editor.org/info/rfc5766>.
[RFC5766] Mahy、R.、Matthews、P.、J。Rosenberg、「NAT（TURN）のリレーを使用したトラバーサル：NATのセッショントラバーサルユーティリティへのリレー拡張（STUN）」、RFC 5766、DOI 10.17487 / RFC5766、4月2010、<http://www.rfc-editor.org/info/rfc5766>。
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, <http://www.rfc-editor.org/info/rfc7092>.
[RFC7092] Kaplan、H。およびV. Pascual、「A Taxonomy of Session Initiation Protocol（SIP）Back-to-Back User Agents」、RFC 7092、DOI 10.17487 / RFC7092、2013年12月、<http：//www.rfc -editor.org/info/rfc7092>。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <http://www.rfc-editor.org/info/rfc3022>.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、DOI 10.17487 / RFC3022、2001年1月、<http://www.rfc-editor.org/info/ rfc3022>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, DOI 10.17487/RFC3424, November 2002, <http://www.rfc-editor.org/info/rfc3424>.
[RFC3424]ダイグル、L。、エド。およびIAB、「ネットワークアドレス変換を介したUNilateral Self-Address Fixing（UNSAF）に関するIABの考慮事項」、RFC 3424、DOI 10.17487 / RFC3424、2002年11月、<http://www.rfc-editor.org/info/rfc3424>。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, <http://www.rfc-editor.org/info/rfc3605>.
[RFC3605] Huitema、C。、「Session Description Protocol（SDP）のReal Time Control Protocol（RTCP）属性」、RFC 3605、DOI 10.17487 / RFC3605、2003年10月、<http://www.rfc-editor.org/ info / rfc3605>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<http://www.rfc-editor.org/ info / rfc4566>。
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, <http://www.rfc-editor.org/info/rfc6888>.
[RFC6888] Perreault、S.、Ed。、Yamagata、I.、Miyakawa、S.、Nakagawa、A.、and H. Ashida、 "Common Requirements for Carrier-Grade NATs（CGNs）"、BCP 127、RFC 6888、 DOI 10.17487 / RFC6888、2013年4月、<http://www.rfc-editor.org/info/rfc6888>。
[RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication", RFC 7362, DOI 10.17487/RFC7362, September 2014, <http://www.rfc-editor.org/info/rfc7362>.
[RFC7362] Ivov、E.、Kaplan、H。、およびD. Wing、「Latching：Hosted NAT Traversal（HNT）for Media in Real-Time Communication」、RFC 7362、DOI 10.17487 / RFC7362、2014年9月、<http： //www.rfc-editor.org/info/rfc7362>。
Acknowledgements
謝辞
Special thanks to Dan Wing, Pal Martinsen, Charles Eckel, Marc Petit-Huguenin, Simon Perreault, Lorenzo Miniero, Ari Keranen, and Parthasarathi Ravindran for their constructive comments, suggestions, and early reviews that were critical to the formulation and refinement of this document.
このドキュメントの作成と改良に重要であった建設的なコメント、提案、初期のレビューについて、Dan Wing、Pal Martinsen、Charles Eckel、Marc Petit-Huguenin、Simon Perreault、Lorenzo Miniero、Ari Keranen、Parthasarathi Ravindranに特に感謝します。 。
Thanks to Ben Campbell, Barry Leiba, Nevil Brownlee, Spencer Dawkins, Sam Hartman, Stephen Farrell, Kathleen Moriarty, and Francis Dupont for their thoughtful review comments.
ベンキャンベル、バリーレイバ、ネビルブラウンリー、スペンサードーキンス、サムハートマン、スティーブンファレル、キャスリーンモリアーティ、フランシスデュポンのレビューに心から感謝します。
Authors' Addresses
著者のアドレス
Ram Mohan Ravindranath Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India
Ram Mohan Rabindranath Cisco Systems、vol。 Sasna Business Park、Varthur Hobli Sarajpur Marthahalli Outer Ring Road Bangalore、Karnatakaインド
Email: rmohanr@cisco.com
Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India
Tirumaleswar Reddy Cisco Systems、Inc. Cessna Business Park、Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore、Karnataka 560103 India
Email: tireddy@cisco.com
Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States
Gonzalo Salgueiro Cisco Systems、Inc. 7200-12 Kit Creek Road Research Triangle Park、NC 27709アメリカ合衆国
Email: gsalguei@cisco.com