[要約] RFC 6947は、SDPのALTC属性に関する仕様であり、セッションの代替接続性を提供するための方法を定義しています。このRFCの目的は、セッションの冗長性や信頼性を向上させるために、複数の接続オプションを提供することです。
Independent Submission M. Boucadair
Request for Comments: 6947 France Telecom
Category: Informational H. Kaplan
ISSN: 2070-1721 Acme Packet
R. Gilman
Independent
S. Veikkolainen
Nokia
May 2013
The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute
セッション記述プロトコル（SDP）代替接続（ALTC）属性
Abstract
概要
This document proposes a mechanism that allows the same SDP offer to carry multiple IP addresses of different address families (e.g., IPv4 and IPv6). The proposed attribute, the "altc" attribute, solves the backward-compatibility problem that plagued Alternative Network Address Types (ANAT) due to their syntax.
このドキュメントは、同じSDPオファーが異なるアドレスファミリ（IPv4やIPv6など）の複数のIPアドレスを伝送できるようにするメカニズムを提案します。提案された属性である「altc」属性は、構文が原因で代替ネットワークアドレスタイプ（ANAT）を悩ましていた下位互換性の問題を解決します。
The proposed solution is applicable to scenarios where connectivity checks are not required. If connectivity checks are required, Interactive Connectivity Establishment (ICE), as specified in RFC 5245, provides such a solution.
提案されたソリューションは、接続性チェックが不要なシナリオに適用できます。接続性チェックが必要な場合、RFC 5245で指定されているInteractive Connectivity Establishment（ICE）がそのようなソリューションを提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc6947.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6947で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 3
1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of the ALTC Mechanism . . . . . . . . . . . . . . . 6
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Rationale for the Chosen Syntax . . . . . . . . . . . . . 7
4. Alternate Connectivity Attribute . . . . . . . . . . . . . . 8
4.1. ALTC Syntax . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Usage and Interaction . . . . . . . . . . . . . . . . . . 9
4.2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Usage of ALTC in an SDP Answer . . . . . . . . . . . 11
4.2.3. Interaction with ICE . . . . . . . . . . . . . . . . 11
4.2.4. Interaction with SDP-Cap-Neg . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. ALTC Use Cases . . . . . . . . . . . . . . . . . . . 15
A.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 15
A.2. Multicast Use Case . . . . . . . . . . . . . . . . . . . 16
A.3. Introducing IPv6 into SIP-Based Architectures . . . . . . 17
A.3.1. Avoiding Crossing CGN Devices . . . . . . . . . . . . 17
A.3.2. Basic Scenario for IPv6 SIP Service Delivery . . . . 17
A.3.3. Avoiding IPv4/IPv6 Interworking . . . . . . . . . . . 18
A.3.4. DBE Bypass Procedure . . . . . . . . . . . . . . . . 20
A.3.5. Direct Communications between IPv6-Enabled User
Agents . . . . . . . . . . . . . . . . . . . . . . . 22
Due to the IPv4 address exhaustion problem, IPv6 deployment is becoming an urgent need, along with the need to properly handle the coexistence of IPv6 and IPv4. The reality of IPv4-IPv6 coexistence introduces heterogeneous scenarios with combinations of IPv4 and IPv6 nodes, some of which are capable of supporting both IPv4 and IPv6 dual-stack (DS) and some of which are capable of supporting only IPv4 or only IPv6. In this context, Session Initiation Protocol (SIP) [RFC3261] User Agents (UAs) need to be able to indicate their available IP capabilities in order to increase the ability to establish successful SIP sessions, to avoid invocation of adaptation functions such as Application Layer Gateways (ALGs) and IPv4-IPv6 interconnection functions (e.g., NAT64 [RFC6146]), and to avoid using private IPv4 addresses through consumer NATs or Carrier-Grade NATs (CGNs) [RFC6888].
IPv4アドレスの枯渇の問題により、IPv6とIPv4の共存を適切に処理する必要性とともに、IPv6の展開が急務となっています。 IPv4-IPv6共存の現実は、IPv4ノードとIPv6ノードの組み合わせによる異種シナリオを導入し、その一部はIPv4とIPv6デュアルスタック（DS）の両方をサポートでき、一部はIPv4のみまたはIPv6のみをサポートできます。このコンテキストでは、セッション開始プロトコル（SIP）[RFC3261]ユーザーエージェント（UA）は、アプリケーションレイヤーなどの適応機能の呼び出しを回避するために、成功するSIPセッションを確立する機能を高めるために、利用可能なIP機能を示すことができる必要があります。ゲートウェイ（ALG）およびIPv4-IPv6相互接続機能（NAT64 [RFC6146]など）、およびコンシューマNATまたはキャリアグレードNAT（CGN）[RFC6888]を介したプライベートIPv4アドレスの使用を回避します。
In the meantime, service providers are investigating scenarios to upgrade their service offering to be IPv6 capable. The current strategies involve either offering IPv6 only, for example, to mobile devices, or providing both IPv4 and IPv6, but with private IPv4 addresses that are NATed by CGNs. In the latter case, the end device may be using "normal" IPv4 and IPv6 stacks and interfaces, or it may tunnel the IPv4 packets though a Dual-Stack Lite (DS-Lite) stack that is integrated into the host [RFC6333]. In either case, the device has both address families available from a SIP and media perspective.
それまでの間、サービスプロバイダーは、サービス提供をIPv6対応にアップグレードするシナリオを調査しています。現在の戦略には、たとえばモバイルデバイスにIPv6のみを提供するか、IPv4とIPv6の両方を提供するが、CGNによってNAT処理されるプライベートIPv4アドレスを使用することが含まれます。後者の場合、エンドデバイスは「通常の」IPv4およびIPv6スタックとインターフェイスを使用している可能性があります。または、ホストに統合されているデュアルスタックライト（DS-Lite）スタックを介してIPv4パケットをトンネルする可能性があります[RFC6333]。どちらの場合も、デバイスにはSIPとメディアの両方の観点から利用可能な両方のアドレスファミリがあります。
Regardless of the IPv6 transition strategy being used, it is obvious that there will be a need for dual-stack SIP devices to communicate with IPv4-only legacy UAs, IPv6-only UAs, and other dual-stack UAs. It may not be possible, for example, for a dual-stack UA to communicate with an IPv6-only UA unless the dual-stack UA has a means of providing the IPv6-only UA with an IPv6 address, while clearly it needs to provide a legacy IPv4-only device an IPv4 address. The communication must be possible in a backward-compatible fashion, such that IPv4-only SIP devices need not support the new mechanism to communicate with dual-stack UAs.
使用されているIPv6移行戦略に関係なく、IPv4のみのレガシーUA、IPv6のみのUA、およびその他のデュアルスタックUAと通信するデュアルスタックSIPデバイスが必要になることは明らかです。たとえば、デュアルスタックUAがIPv6のみのUAと通信することは、デュアルスタックUAがIPv6のみのUAにIPv6アドレスを提供する手段を備えていない限り、不可能である可能性があります。レガシーIPv4専用デバイス、IPv4アドレス。 IPv4のみのSIPデバイスがデュアルスタックUAと通信するための新しいメカニズムをサポートする必要がないように、通信は下位互換性のある方法で可能でなければなりません。
The current means by which multiple address families can be communicated are through ANAT [RFC4091] or ICE [RFC5245]. ANAT has serious backward-compatibility problems, as described in [RFC4092], which effectively make it unusable, and it has been deprecated by the IETF [RFC5245]. ICE at least allows interoperability with legacy devices. But, ICE is a complicated and processing-intensive mechanism and has seen limited deployment and implementation in SIP applications.
複数のアドレスファミリを通信できる現在の手段は、ANAT [RFC4091]またはICE [RFC5245]を介したものです。 [RFC4092]で説明されているように、ANATには重大な下位互換性の問題があるため、実質的に使用できなくなり、IETF [RFC5245]で非推奨になりました。 ICEでは、少なくともレガシーデバイスとの相互運用が可能です。ただし、ICEは複雑で処理集約型のメカニズムであり、SIPアプリケーションでの展開と実装は制限されています。
ALTC has been implemented as reported in [NAT64-EXP]. No issues have been reported in that document.
ALTCは[NAT64-EXP]で報告されているように実装されています。その文書では問題は報告されていません。
This document proposes a new alternative: a backward-compatible syntax for indicating multiple media connection addresses and ports in an SDP offer, which can immediately be selected from and used in an SDP answer.
このドキュメントでは、新しい代替案を提案します。SDPオファーで複数のメディア接続アドレスとポートを示すための下位互換性のある構文で、SDP回答からすぐに選択して使用できます。
The proposed mechanism is independent of the model described in [RFC5939] and does not require implementation of SDP Capability Negotiations (a.k.a., SDPCapNeg) to function.
提案されたメカニズムは、[RFC5939]で説明されているモデルから独立しており、機能するためにSDP機能ネゴシエーション（別名、SDPCapNeg）の実装を必要としません。
It should be noted that "backward-compatible" in this document generally refers to working with legacy IPv4-only devices. The choice has to be made, one way or the other, because to interoperate with legacy devices requires constructing SDP bodies that they would understand and support, such that they detect their local address family in the SDP connection line. It is not possible to support interworking with both legacy IPv4-only and legacy IPv6-only devices with the same SDP offer. Clearly, there are far more legacy IPv4-only devices in existence, and thus those are the ones assumed in this document. However, the syntax allows for a UA to choose which address family to be backward-compatible with, in case it has some means of determining it.
このドキュメントの「下位互換性」とは、一般にレガシーIPv4専用デバイスでの作業を指すことに注意してください。レガシーデバイスと相互運用するには、SDP接続回線でローカルアドレスファミリを検出できるように、理解してサポートするSDP本体を構築する必要があるため、どちらかを選択する必要があります。同じSDPオファーで、レガシーIPv4のみのデバイスとレガシーIPv6のみのデバイスの両方とのインターワーキングをサポートすることはできません。明らかに、はるかに多くのレガシーIPv4専用デバイスが存在するため、これらはこのドキュメントで想定されているものです。ただし、構文によって、UAは、それを決定する何らかの手段がある場合に備えて、下位互換性のあるアドレスファミリを選択できます。
Furthermore, even for cases where both sides support the same address family, there should be a means by which the "best" address family transport is used, based on what the UAs decide. The address family that is "best" for a particular session cannot always be known a priori. For example, in some cases the IPv4 transport may be better, even if both UAs support IPv6.
さらに、双方が同じアドレスファミリをサポートする場合でも、UAが決定するものに基づいて、「最良の」アドレスファミリトランスポートが使用される手段が必要です。特定のセッションに「最適」なアドレスファミリは、常にアプリオリに知ることができるとは限りません。たとえば、両方のUAがIPv6をサポートしている場合でも、IPv4トランスポートの方が優れている場合があります。
The proposed solution provides the following benefits:
提案されたソリューションには、次の利点があります。
o Allows a UA to signal more than one IP address (type) in the same SDP offer.
o UAが同じSDPオファーで複数のIPアドレス（タイプ）を通知できるようにします。
o Is backward compatible. No parsing or semantic errors will be experienced by a legacy UA or by intermediary SIP nodes that do not understand this new mechanism.
o 下位互換性があります。レガシーUAや、この新しいメカニズムを理解しない中間のSIPノードでは、解析エラーやセマンティックエラーは発生しません。
o Is as lightweight as possible to achieve the goal, while still allowing and interoperating with nodes that support other similar or related mechanisms.
o 他の同様または関連するメカニズムをサポートするノードを許可および相互運用しながら、目標を達成するために可能な限り軽量です。
o Is easily deployable in managed networks.
o 管理されたネットワークに簡単に展開できます。
o Requires minimal increase of the length of the SDP offer (i.e., minimizes fragmentation risks).
o SDPオファーの長さの最小限の増加を必要とします（つまり、断片化のリスクを最小限に抑えます）。
ALTC may also be useful for the multicast context (e.g., Section 3.4 of [MULTRANS-FW] or Section 3.3 of [ADDR-ACQ]).
ALTCは、マルチキャストコンテキストにも役立ちます（たとえば、[MULTRANS-FW]のセクション3.4または[ADDR-ACQ]のセクション3.3）。
More detailed information about ALTC use cases is provided in Appendix A.
ALTCの使用例の詳細については、付録Aを参照してください。
This document proposes an alternative scheme, as a replacement to the ANAT procedure [RFC4091], to carry several IP address types in the same SDP offer while preserving backward compatibility.
このドキュメントでは、ANATプロシージャ[RFC4091]の代替として、下位互換性を維持しながら同じSDPオファーで複数のIPアドレスタイプを伝送する代替スキームを提案しています。
While two UAs communicating directly at a SIP layer clearly need to be able to support the same address family for SIP itself, current SIP deployments almost always have proxy servers or back-to-back user agents (B2BUAs) in the SIP signaling path, which can provide the necessary interworking of the IP address family at the SIP layer (e.g., [RFC6157]). SIP-layer address family interworking is out of scope of this document. Instead, this document focuses on the problem of communicating media address family capabilities in a backward-compatible fashion. Because media can go directly between two UAs, without a priori knowledge by the User Agent Client (UAC) of which address family the far-end User Agent Server (UAS) supports, it has to offer both, in a backward-compatible fashion.
SIP層で直接通信する2つのUAは明らかにSIP自体に同じアドレスファミリをサポートできる必要がありますが、現在のSIP展開ではほとんどの場合、SIPシグナリングパスにプロキシサーバーまたはバックツーバックユーザーエージェント（B2BUA）があり、 SIP層でIPアドレスファミリの必要なインターワーキングを提供できます（[RFC6157]など）。 SIPレイヤアドレスファミリインターワーキングは、このドキュメントの範囲外です。代わりに、このドキュメントでは、下位互換性のある方法でメディアアドレスファミリ機能を通信する問題に焦点を当てています。メディアは、2つのUA間を直接移動できるため、遠端のユーザーエージェントサーバー（UAS）がサポートするアドレスファミリをユーザーエージェントクライアント（UAC）が事前に認識していなくても、下位互換性のある方法で両方を提供する必要があります。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The ALTC mechanism defined in this document is primarily meant for managed networks. In particular, the following use cases were explicitly considered:
このドキュメントで定義されているALTCメカニズムは、主に管理対象ネットワークを対象としています。特に、次の使用例が明示的に検討されました。
o A dual-stack UAC that initiates a SIP session without knowing the address family of the ultimate target UAS.
o 最終的なターゲットUASのアドレスファミリを知らなくてもSIPセッションを開始するデュアルスタックUAC。
o A UA that receives a SIP session request with SDP offer and that wishes to avoid using IPv4 or IPv6.
o SDPオファーを含むSIPセッション要求を受信し、IPv4またはIPv6の使用を回避したいUA。
o An IPv6-only UA that wishes to avoid using a NAT64 [RFC6146].
o NAT64 [RFC6146]の使用を避けたいIPv6のみのUA。
o A SIP UA behind a DS-Lite CGN [RFC6333].
o DS-Lite CGN [RFC6333]の背後にあるSIP UA。
o A SIP service provider or enterprise domain of an IPv4-only and/or IPv6-only UA that provides interworking by invoking IPv4-IPv6 media relays and that wishes to avoid invoking such functions and to let media go end to end as much as possible.
o IPv4のみまたはIPv6のみのUAのSIPサービスプロバイダーまたはエンタープライズドメイン。IPv4-IPv6メディアリレーを呼び出すことによりインターワーキングを提供し、そのような機能の呼び出しを回避し、メディアを可能な限りエンドツーエンドにさせます。
o A SIP service provider or enterprise domain of a UA that communicates with other domains and that wishes either to avoid invoking IPv4-IPv6 interworking or to let media go end to end as much as possible.
o 他のドメインと通信し、IPv4-IPv6インターワーキングの呼び出しを回避するか、メディアを可能な限りエンドツーエンドにしたいUAのSIPサービスプロバイダーまたはエンタープライズドメイン。
o A SIP service provider that provides transit peering services for SIP sessions that may need to modify SDP in order to provide IPv4-IPv6 interworking, but would prefer to avoid such interworking or to avoid relaying media in general, as much as possible.
o IPv4-IPv6インターワーキングを提供するためにSDPを変更する必要がある可能性があるが、そのようなインターワーキングを回避するか、一般的にメディアのリレーをできるだけ回避することを望むSIPセッションにトランジットピアリングサービスを提供するSIPサービスプロバイダー。
o SIP sessions that use the new mechanism when crossing legacy SDP-aware middleboxes, but that may not understand this new mechanism.
o レガシーSDP対応ミドルボックスを通過するときに新しいメカニズムを使用するSIPセッション。ただし、この新しいメカニズムは理解できない場合があります。
The ALTC mechanism relies solely on the SDP offer/answer mechanism, with specific syntax to indicate alternative connection addresses. The basic concept is to use a new SDP attribute, "altc", to indicate the IP addresses for potential alternative connection addresses. The address that is most likely to get chosen for the session is in the normal "c=" line. Typically, in current operational networks, this would be an IPv4 address. The "a=altc" lines contain the alternative addresses offered for this session. This way, a dual-stack UA might encode its IPv4 address in the "c=" line, while possibly preferring to use an IPv6 address by explicitly indicating the preference order in the corresponding "a=altc" line. One of the "a=altc" lines duplicates the address contained in the "c=" line, for reasons explained in Section 3.2. The SDP answerer would indicate its chosen address by simply using that address family in the "c=" line of its response.
ALTCメカニズムは、SDPオファー/アンサーメカニズムのみに依存し、代替の接続アドレスを示す特定の構文を備えています。基本的な概念は、新しいSDP属性「altc」を使用して、潜在的な代替接続アドレスのIPアドレスを示すことです。セッションで選択される可能性が最も高いアドレスは、通常の「c =」行にあります。通常、現在の運用ネットワークでは、これはIPv4アドレスになります。 "a = altc"行には、このセッションに提供される代替アドレスが含まれています。このように、デュアルスタックUAはIPv4アドレスを「c =」行にエンコードする一方で、対応する「a = altc」行で優先順位を明示的に示すことにより、IPv6アドレスを使用することを好む可能性があります。セクション3.2で説明する理由により、「a = altc」行の1つが「c =」行に含まれるアドレスと重複しています。 SDPアンサーは、応答の "c ="行でそのアドレスファミリを使用するだけで、選択したアドレスを示します。
An example of an SDP offer using this mechanism is as follows when IPv4 is considered most likely to be used for the session, but IPv6 is preferred:
このメカニズムを使用したSDPオファーの例は、IPv4がセッションに使用される可能性が最も高いと考えられる場合は次のとおりですが、IPv6が推奨されます。
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 12340 RTP/AVP 0 8
a=altc:1 IP6 2001:db8::1 45678
a=altc:2 IP4 192.0.2.1 12340
If IPv6 were considered more likely to be used for the session, the SDP offer would be as follows:
IPv6がセッションで使用される可能性が高いと見なされた場合、SDPオファーは次のようになります。
v=0
o=- 25678 753849 IN IP6 2001:db8::1
s=
c=IN IP6 2001:db8::1
t=0 0
m=audio 45678 RTP/AVP 0 8
a=altc:1 IP6 2001:db8::1 45678
a=altc:2 IP4 192.0.2.1 12340
Since an alternative address is likely to require an alternative TCP/UDP port number as well, the new "altc" attribute includes both an IP address and a transport port number (or multiple port numbers). The ALTC mechanism does not itself support offering a different transport type (i.e., UDP vs. TCP), codec, or any other attribute. It is intended only for offering an alternative IP address and port number.
代替アドレスには代替TCP / UDPポート番号も必要になる可能性が高いため、新しい「altc」属性には、IPアドレスとトランスポートポート番号（または複数のポート番号）の両方が含まれます。 ALTCメカニズム自体は、異なるトランスポートタイプ（つまり、UDPとTCP）、コーデック、またはその他の属性の提供をサポートしていません。これは、代替のIPアドレスとポート番号を提供することのみを目的としています。
The use of an "a=" attribute line is, according to [RFC4566], the primary means for extending SDP and tailoring it to particular applications or media. A compliant SDP parser will ignore the unsupported attribute lines.
[RFC4566]によれば、 "a ="属性行の使用は、SDPを拡張して特定のアプリケーションまたはメディアに合わせて調整するための主要な手段です。準拠しているSDPパーサーは、サポートされていない属性行を無視します。
The rationale for encoding the same address and port in the "a=altc" line as in the "m=" and "c=" lines is to provide detection of legacy SDP-changing middleboxes. Such systems may change the connection address and media transport port numbers, but not support this new mechanism, and thus two UAs supporting this mechanism would try to connect to the wrong addresses. Therefore, this document requires the SDP processor to proceed to the matching rules defined in Section 4.2.1.
「m =」および「c =」行と同じ「a = altc」行で同じアドレスとポートをエンコードする根拠は、レガシーSDP変更ミドルボックスの検出を提供することです。そのようなシステムは、接続アドレスとメディアトランスポートポート番号を変更する可能性がありますが、この新しいメカニズムをサポートしていないため、このメカニズムをサポートする2つのUAが間違ったアドレスに接続しようとします。したがって、このドキュメントでは、SDPプロセッサがセクション4.2.1で定義されている一致ルールに進む必要があります。
The "altc" attribute adheres to the [RFC4566] "attribute" production. The ABNF syntax [RFC5234] of altc is provided below.
「altc」属性は、[RFC4566]の「属性」プロダクションに準拠しています。 altcのABNF構文[RFC5234]を以下に示します。
altc-attr = "altc" ":" att-value
att-value = altc-num SP addrtype SP connection-address SP port
["/" rtcp-port]
altc-num = 1*DIGIT
rtcp-port = port
Figure 1: Connectivity Capability Attribute ABNF
図1：接続機能の属性ABNF
The meaning of the fields are as follows:
フィールドの意味は次のとおりです。
o altc-num: digit to uniquely refer to an address alternative. It indicates the preference order, with "1" indicated the most preferred address.
o altc-num：代替アドレスを一意に参照するための数字。これは優先順位を示し、「1」は最も優先されるアドレスを示します。
o addrtype: the addrtype field as defined in [RFC4566] for connection data.
o addrtype：[RFC4566]で定義されている接続データのaddrtypeフィールド。
o connection-address: a network address as defined in [RFC4566] corresponding to the address type specified by addrtype.
o connection-address：addrtypeで指定されたアドレスタイプに対応する、[RFC4566]で定義されているネットワークアドレス。
o port: the port number to be used, as defined in [RFC4566]. Distinct port numbers may be used for each IP address type. If the specified address type does not require a port number, a value defined for that address type should be used.
o port：[RFC4566]で定義されている、使用するポート番号。それぞれのIPアドレスタイプに異なるポート番号を使用できます。指定されたアドレスタイプにポート番号が必要ない場合は、そのアドレスタイプに定義されている値を使用する必要があります。
o rtcp-port: including an RTP Control Protocol (RTCP) port is optional. An RTCP port may be indicated in the alternative "c=" line when the RTCP port cannot be derived from the RTP port.
o rtcp-port：RTP制御プロトコル（RTCP）ポートの組み込みはオプションです。 RTCPポートがRTPポートから取得できない場合、RTCPポートは代替の「c =」行に示される場合があります。
The "altc" attribute is applicable only in an SDP offer. The "altc" attribute is a media-level-only attribute and MUST NOT appear at the SDP session level. (Because it defines a port number, it is inherently tied to the media level.) There MUST NOT be more than one "altc" attribute per addrtype within each media description. This restriction is necessary so that the addrtype of the reply may be used by the offerer to determine which alternative was accepted.
「altc」属性は、SDPオファーにのみ適用されます。 「altc」属性はメディアレベルのみの属性であり、SDPセッションレベルで表示してはなりません。 （これはポート番号を定義するため、本質的にメディアレベルに関連付けられます。）各メディア記述内のaddrtypeごとに複数の「altc」属性があってはなりません。この制限は、提供者が応答のaddrtypeを使用して、どの代替案が受け入れられたかを判断できるようにするために必要です。
The "addrtype"s of the altc MUST correspond to the "nettype" of the current connection ("c=") line.
altcの「addrtype」は、現在の接続（「c =」）行の「nettype」に対応している必要があります。
A media description MUST contain two "altc" attributes: the alternative address and an alternative port. It must also contain an address and a port that "duplicate" the address/port information from the current "c=" and "m=" lines. Each media level MUST contain at least one such duplicate "altc" attribute, of the same IP address family, address, and transport port number as those in the SDP connection and media lines of its level. In particular, if a "c=" line appears within a media description, the addrtype and connection-address from that "c=" line MUST be used in the duplicate "altc" attribute for that media description. If a "c=" line appears only at the session level and a given media description does not have its own connection line, then the duplicate "altc" attribute for that media description MUST be the same as the session-level address information.
メディア記述には、代替アドレスと代替ポートの2つの「altc」属性を含める必要があります。また、現在の「c =」行と「m =」行からのアドレス/ポート情報を「複製」するアドレスとポートも含まれている必要があります。各メディアレベルには、そのレベルのSDP接続およびメディアラインと同じIPアドレスファミリ、アドレス、およびトランスポートポート番号の、このような重複する「altc」属性を少なくとも1つ含める必要があります。特に、「c =」行がメディア記述内に表示される場合、その「c =」行のaddrtypeおよびconnection-addressは、そのメディア記述の重複する「altc」属性で使用する必要があります。 「c =」行がセッションレベルでのみ表示され、特定のメディア記述に独自の接続行がない場合、そのメディア記述の重複する「altc」属性は、セッションレベルのアドレス情報と同じである必要があります。
The "altc" attributes appearing within a media description MUST be prioritized. The explicit preference order is indicated in each line ("1" indicates the address with the highest priority). Given this rule, and the requirement that the address information provided in the "m=" line and "o=" line must be provided in an "altc" attribute as well, it is possible that the addresses in the "m=" line and "o=" line are not the preferred choice.
メディア記述内に現れる「altc」属性は優先されなければなりません。明示的な優先順位は各行に示されます（「1」は最も優先度の高いアドレスを示します）。このルールと、「m =」行および「o =」行で提供されるアドレス情報を「altc」属性でも提供する必要があるという要件がある場合、「m =」行のアドレスがおよび「o =」行は推奨されません。
If the addrtype of an "altc" attribute is not compatible with the transport protocol or media format specified in the media description, that "altc" attribute MUST be ignored.
「altc」属性のaddrtypeが、メディアの説明で指定されているトランスポートプロトコルまたはメディアフォーマットと互換性がない場合、その「altc」属性は無視する必要があります。
Note that "a=altc" lines describe alternative connection addresses, NOT addresses for parallel connections. When several "altc" lines are present, establishing multiple sessions MUST be avoided. Only one session is to be maintained with the remote party for the associated media description.
「a = altc」の行は代替接続アドレスを示しており、並列接続のアドレスではないことに注意してください。複数の「altc」行が存在する場合は、複数のセッションの確立を回避する必要があります。関連するメディアの説明のために、リモートパーティとの間に維持されるセッションは1つだけです。
In an SDP offer/answer model, the SDP offer includes "altc" attributes to indicate alternative connection information (i.e., address type, address and port numbers), including the "duplicate" connection information already identified in the "c=" and "m=" lines.
SDPオファー/アンサーモデルでは、SDPオファーに「altc」属性が含まれ、「c =」と「」で既に識別されている「重複」接続情報を含む、代替接続情報（アドレスタイプ、アドレス、ポート番号）を示します。 m = "行。
Additional, subsequent offers MAY include "altc" attributes again, and they may change the IP address, port numbers, and order of preference, but they MUST include a duplicate "altc" attribute for the connection and media lines in that specific subsequent offer. In other words, every offered SDP media description with an alternative address offer with an "altc" attribute has two "altc" attributes:
追加の後続オファーには「altc」属性が再度含まれる場合があり、IPアドレス、ポート番号、および優先順位が変更される可能性がありますが、それらの特定の後続オファーの接続とメディア回線に重複する「altc」属性を含める必要があります。言い換えると、「altc」属性を持つ代替アドレスオファーで提供されるすべてのSDPメディア記述には、2つの「altc」属性があります。
- one duplicating the "c=" and "m=" line information for that media description
- そのメディアの説明の「c =」と「m =」の行情報を複製するもの
- one for the alternative
- 代わりの1つ
These need not be the same as the original SDP offer.
これらは、元のSDPオファーと同じである必要はありません。
The purpose of encoding a duplicate "altc" attribute is to allow receivers of the SDP offer to detect if a legacy SDP-changing middlebox has modified the "c=" and/or "m=" line address/port information. If the SDP answerer does not find a duplicate "altc" attribute value for which the address and port exactly match those in the "c=" line and "m=" line, the SDP answerer MUST ignore the "altc" attributes and use the "c=" and "m=" offered address/ports for the entire SDP instead, as if no "altc" attributes were present. The rationale for this is that many SDP-changing middleboxes will end the media sessions if they do not detect media flowing through them. If a middlebox modified the SDP addresses, media MUST be sent using the modified information.
重複する「altc」属性をエンコードする目的は、SDPオファーの受信者がレガシーSDP変更ミドルボックスが「c =」または「m =」行アドレス/ポート情報を変更したかどうかを検出できるようにすることです。 SDPアンサーが、アドレスとポートが「c =」行と「m =」行の値と正確に一致する「altc」属性値が重複していない場合、SDPアンサーは「altc」属性を無視して、 「c =」と「m =」は、「altc」属性が存在しないかのように、代わりにSDP全体にアドレス/ポートを提供しました。この理由は、SDPを変更する多くのミドルボックスは、それらを通過するメディアを検出しない場合、メディアセッションを終了するということです。ミドルボックスがSDPアドレスを変更した場合、変更された情報を使用してメディアを送信する必要があります。
Note that for RTCP, if applicable for the given media types, each side would act as if the chosen "altc" attribute's port number was in the "m=" media line. Typically, this would mean that RTCP is sent to the port number equal to "RTP port + 1", unless some other attribute determines otherwise. For example, the RTP/RTCP multiplexing mechanism defined in [RFC5761] can still be used with ALTC, such that if both sides support multiplexing, they will indicate so using the "a=rtcp-mux" attribute, as defined in [RFC5761], but the IP connection address and port they use may be chosen using the ALTC mechanism.
RTCPの場合、特定のメディアタイプに該当する場合、各サイドは、選択された「altc」属性のポート番号が「m =」メディア行にあるかのように動作することに注意してください。通常、これは、RTCPが「RTPポート+ 1」に等しいポート番号に送信されることを意味します。たとえば、[RFC5761]で定義されたRTP / RTCP多重化メカニズムは引き続きALTCで使用でき、両側が多重化をサポートしている場合は、[RFC5761]で定義されている「a = rtcp-mux」属性を使用してそのように示します。ただし、それらが使用するIP接続アドレスとポートは、ALTCメカニズムを使用して選択できます。
If the SDP offerer wishes to use the RTCP attribute defined in [RFC3605], a complication can arise, since it may not be clear which address choice the "a=rtcp" attribute applies to, relative to the choices offered by ALTC. Technically, RFC 3605 allows the address for RTCP to be indicated explicitly in the "a=rtcp" attribute itself, but this is optional and rarely used. For this reason, this document recommends using the "a=rtcp" attribute for the address choice encoded in the "m=" line and including an alternate RTCP port in the "a=altc" attribute corresponding to the alternative address. In other words, if the "a=rtcp" attribute explicitly encodes an address in its attribute, that address applies for ALTC, as per [RFC3605]. If it does not, then ALTC assumes that the "a=rtcp" attribute is for the address in the "m=" line, and the alternative "altc" attribute includes an RTCP alternate port number.
SDP提供者が[RFC3605]で定義されているRTCP属性を使用したい場合、ALTCが提供する選択肢と比較して、「a = rtcp」属性がどのアドレス選択に適用されるかが明確でない場合があるため、複雑になる可能性があります。技術的には、RFC 3605では、RTCPのアドレスを「a = rtcp」属性自体に明示的に示すことができますが、これはオプションであり、ほとんど使用されません。このため、このドキュメントでは、「m =」行でエンコードされたアドレス選択に「a = rtcp」属性を使用し、代替アドレスに対応する「a = altc」属性に代替RTCPポートを含めることを推奨しています。言い換えると、「a = rtcp」属性がその属性のアドレスを明示的にエンコードする場合、そのアドレスは[RFC3605]に従ってALTCに適用されます。そうでない場合、ALTCは「a = rtcp」属性が「m =」行のアドレス用であると想定し、代替の「altc」属性にはRTCP代替ポート番号が含まれます。
The SDP answer SHOULD NOT contain "altc" attributes, because the answer's "c=" line implicitly and definitively chooses the address family from the offer and includes it in "c=" and "m=" lines of the answer. Furthermore, this avoids establishing several sessions simultaneously between the participating peers.
SDP回答には「altc」属性を含めないでください。回答の「c =」行が暗黙的かつ確実にオファーからアドレスファミリを選択し、回答の「c =」および「m =」行に含めます。さらに、これにより、参加するピア間で同時に複数のセッションを確立することが回避されます。
Any solution requiring the use of ALTC in the SDP answer SHOULD document its usage, in particular how sessions are established between the participating peers.
SDP回答でALTCの使用を必要とするソリューションは、その使用法、特に参加しているピア間でセッションが確立される方法を文書化する必要があります（SHOULD）。
Since ICE [RFC5245] also includes address and port number information in its candidate attributes, a potential problem arises: which one wins. Since ICE also includes specific ICE attributes in the SDP answer, the problem is easily avoided: if the SDP offerer supports both ALTC and ICE, it may include both sets of attributes in the same SDP offer. A legacy ICE-only answerer will simply ignore the "altc" attributes and use ICE. An ALTC-only answerer will ignore the ICE attributes and reply without them. An answerer that supports both MUST choose one and only one of the mechanisms to use: either ICE or ALTC. However, if the "m=" or "c=" line was changed by a middlebox, the rules for both ALTC and ICE would make the answerer revert to basic SDP semantics.
ICE [RFC5245]の候補属性にはアドレスとポート番号の情報も含まれているため、どちらが勝つかという潜在的な問題が発生します。 ICEはSDP回答に特定のICE属性も含まれているため、問題は簡単に回避できます。SDP提供者がALTCとICEの両方をサポートしている場合、同じSDP提供に両方の属性セットが含まれる場合があります。従来のICEのみの回答者は、「altc」属性を無視してICEを使用します。 ALTCのみの応答者はICE属性を無視し、それらなしで応答します。両方をサポートする回答者は、使用するメカニズムの1つだけを選択する必要があります（ICEまたはALTCのいずれか）。ただし、「m =」または「c =」行がミドルボックスによって変更された場合、ALTCとICEの両方のルールにより、回答者は基本的なSDPセマンティクスに戻ります。
The ALTC mechanism is orthogonal to SDPCapNeg [RFC5939]. If the offerer supports both ALTC and SDPCapNeg, it may offer both.
ALTCメカニズムはSDPCapNeg [RFC5939]と直交しています。提供者がALTCとSDPCapNegの両方をサポートしている場合、両方を提供できます。
Per this document, the following new SDP attribute has been assigned.
このドキュメントによれば、次の新しいSDP属性が割り当てられています。
SDP Attribute ("att-field"):
SDP属性（ "att-field"）：
Attribute name altc Long form Alternate Connectivity Type of name att-field Type of attribute Media level only Subject to charset No Purpose See Sections 1.2 and 3 Specification Section 4
属性名altc長い形式代替接続性名前のタイプatt-field属性のタイプメディアレベルのみcharsetの対象なし目的セクション1.2および3を参照仕様セクション4
The contact person for this registration is Mohamed Boucadair (email: mohamed.boucadair@orange.com; phone: +33 2 99 12 43 71).
この登録の担当者はMohamed Boucadair（メール：mohamed.boucadair@orange.com、電話：+33 2 99 12 43 71）です。
The security implications for ALTC are effectively the same as they are for SDP in general [RFC4566].
ALTCのセキュリティへの影響は、一般にSDPの場合と実質的に同じです[RFC4566]。
Many thanks to T. Taylor, F. Andreasen, and G. Camarillo for their review and comments.
T. Taylor、F。Andreasen、G。Camarilloのレビューとコメントに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、2002年6月。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[RFC3605] Huitema、C。、「Session Description Protocol（SDP）のReal Time Control Protocol（RTCP）属性」、RFC 3605、2003年10月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761] Perkins、C。およびM. Westerlund、「Multiplexing RTP Data and Control Packets on a Single Port」、RFC 5761、2010年4月。
[ADDR-ACQ] Tsou, T., Clauberg, A., Boucadair, M., Venaas, S., and Q. Sun, "Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions", Work in Progress, January 2013.
[ADDR-ACQ] Tsou、T.、Clauberg、A.、Boucadair、M.、Venaas、S。、およびQ. Sun、「ソースとレシーバが異なるIPバージョンをサポートする場合のマルチキャストコンテンツのアドレス取得」、進行中の作業、 2013年1月。
[ADDR-FORMAT] Boucadair, M., Ed., Qin, J., Lee, Y., Venaas, S., Li, X., and M. Xu, "IPv6 Multicast Address With Embedded IPv4 Multicast Address", Work in Progress, April 2013.
[ADDR-FORMAT] Boucadair、M.、Ed。、Qin、J.、Lee、Y.、Venaas、S.、Li、X.、and M. Xu、 "IPv6 Multicast Address With Embedded IPv4 Multicast Address"、Work進行中、2013年4月。
[MULTRANS-FW] Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6 Multicast Translation", Work in Progress, June 2011.
[MULTRANS-FW] Venaas、S.、Li、X.、C。Bao、「Framework for IPv4 / IPv6 Multicast Translation」、Work in Progress、2011年6月。
[MULTRANS-PS] Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T., and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and Use Cases", Work in Progress, March 2013.
[MULTRANS-PS] Jacquenet、C.、Boucadair、M.、Lee、Y.、Qin、J.、Tsou、T。、およびQ. Sun、「IPv4-IPv6 Multicast：Problem Statement and Use Cases」、Work in進捗状況、2013年3月。
[NAT64-EXP] Abdesselam, M., Boucadair, M., Hasnaoui, A., and J. Queiroz, "PCP NAT64 Experiments", Work in Progress, September 2012.
[NAT64-EXP] Abdesselam、M.、Boucadair、M.、Hasnaoui、A。、およびJ. Queiroz、「PCP NAT64 Experiments」、Work in Progress、2012年9月。
[RFC2871] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony Routing over IP", RFC 2871, June 2000.
[RFC2871] Rosenberg、J。およびH. Schulzrinne、「A IPを介したテレフォニールーティングのフレームワーク」、RFC 2871、2000年6月。
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC4091] Camarillo、G。およびJ. Rosenberg、「セッション記述プロトコル（SDP）グループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクス」、RFC 4091、2005年6月。
[RFC4092] Camarillo, G. and J. Rosenberg, "Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)", RFC 4092, June 2005.
[RFC4092] Camarillo、G。およびJ. Rosenberg、「Session Description Protocol（SDP）代替ネットワークアドレスタイプ（ANAT）セマンティクスのSession Initiation Protocol（SIP）での使用」、RFC 4092、2005年6月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、2010年4月。
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
[RFC5853] Hautakorpi、J.、Camarillo、G.、Penfield、R.、Hawrylyshen、A。、およびM. Bhatia、「Session Initiation Protocol（SIP）Session Border Control（SBC）Deployments from Requirements」、RFC 5853、4月2010。
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010.
[RFC5939] Andreasen、F。、「Session Description Protocol（SDP）Capability Negotiation」、RFC 5939、2010年9月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「Stateful NAT64：Network Address and Protocol Translation to IPv6 Clients to IPv4 Servers」、RFC 6146、2011年4月。
[RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", RFC 6157, April 2011.
[RFC6157] Camarillo、G.、El Malki、K。、およびV. Gurbani、「IPv6 Transition in the Session Initiation Protocol（SIP）」、RFC 6157、2011年4月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、2011年8月。
[RFC6406] Malas, D. and J. Livingood, "Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture", RFC 6406, November 2011.
[RFC6406] Malas、D。およびJ. Livingood、「マルチメディアINTerconnect（SPEERMINT）アーキテクチャのセッションPEERing」、RFC 6406、2011年11月。
[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013.
[RFC6888] Perreault、S。、山形、I。、宮川、S。、中川、A。、およびH. Ashida、「Common Requirements for Carrier-Grade NATs（CGNs）」、BCP 127、RFC 6888、2013年4月。
The following terms are used when discussing the ALTC use cases:
次の用語は、ALTCの使用例を説明するときに使用されます。
o SBE (Signaling Path Border Element) denotes a functional element, located at the boundaries of an ITAD (IP Telephony Administrative Domain) [RFC2871], that is responsible for intercepting signaling flows received from UAs and relaying them to the core service platform. An SBE may be located at the access segment (i.e., be the service contact point for UAs), or be located at the interconnection with adjacent domains [RFC6406]. An SBE controls one or more DBEs. The SBE and DBE may be located in the same device (e.g., the SBC [RFC5853]) or be separated.
o SBE（Signaling Path Border Element）は、UAから受信したシグナリングフローを傍受し、コアサービスプラットフォームに中継する役割を持つITAD（IPテレフォニー管理ドメイン）[RFC2871]の境界にある機能要素を示します。 SBEは、アクセスセグメントに配置される（つまり、UAのサービスコンタクトポイントになる）か、隣接ドメインとの相互接続に配置されます[RFC6406]。 SBEは1つ以上のDBEを制御します。 SBEとDBEは同じデバイス（たとえば、SBC [RFC5853]）に配置するか、分離することができます。
o DBE (Data Path Border Element) denotes a functional element, located at the boundaries of an ITAD, that is responsible for intercepting media/data flows received from UAs and relaying them to another DBE (or media servers, e.g., an announcement server or IVR). An example of a DBE is a media gateway that intercepts RTP flows. An SBE may be located at the access segment (i.e., be the service contact point for UAs) or be located at the interconnection with adjacent domains ([RFC6406]).
o DBE（データパス境界要素）は、UAから受信したメディア/データフローを傍受し、それらを別のDBE（またはアナウンスサーバーやIVRなどのメディアサーバー）に中継する役割を持つ、ITADの境界にある機能要素を示します。 ）。 DBEの例は、RTPフローを傍受するメディアゲートウェイです。 SBEは、アクセスセグメントに配置される（つまり、UAのサービスコンタクトポイントになる）か、隣接するドメインとの相互接続に配置される（[RFC6406]）。
o Core service platform ("core SPF") is a macro functional block including session routing, interfaces to advanced services, and access control.
o コアサービスプラットフォーム（「コアSPF」）は、セッションルーティング、高度なサービスへのインターフェイス、アクセス制御などのマクロ機能ブロックです。
Figure 2 provides an overview of the overall architecture, including the SBE, DBE, and core service platform.
図2は、SBE、DBE、コアサービスプラットフォームなど、アーキテクチャ全体の概要を示しています。
+----------+
| Core SIP |
+--------->| SPF |<---------+
| SIP +----------+ SIP |
v v
+-----------+ +-----------+
+-----+ SIP | SBE | | SBE | SIP
| S |<----->| | | |<----->
| I | +-----------+ +-----------+
| P | || ||
| | +-----------+ +-----------+
| U | RTP | DBE | RTP | DBE | RTP
| A |<----->| |<----------------->| | <----->
+-----+ +-----------+ +-----------+
SIP UA can be embedded in the CPE or in a host behind the CPE
SIP UAは、CPEまたはCPEの背後のホストに組み込むことができます。
Figure 2: Service Architecture Overview
図2：サービスアーキテクチャの概要
Recently, a significant effort has been undertaken within the IETF to specify new mechanisms to interconnect IPv6-only hosts to IPv4-only servers (e.g., [RFC6146]). This effort exclusively covered unicast transfer mode. An ongoing initiative, called "multrans", has been launched to cover multicast issues that are encountered during IPv6 transition. The overall problem statement is documented in [MULTRANS-PS].
最近、IPv6のみのホストをIPv4のみのサーバーに相互接続する新しいメカニズムを指定するために、IETF内で多大な努力が払われています（たとえば、[RFC6146]）。この取り組みは、ユニキャスト転送モードのみを対象としていました。 「multrans」と呼ばれる進行中のイニシアチブは、IPv6の移行中に発生するマルチキャストの問題をカバーするために開始されました。全体的な問題の説明は[MULTRANS-PS]に文書化されています。
A particular issue encountered in the context of IPv4/IPv6 coexistence and IPv6 transition of multicast services is the discovery of the multicast group and source (refer to Section 3.4 of [MULTRANS-PS]):
マルチキャストサービスのIPv4 / IPv6共存とIPv6移行のコンテキストで発生する特定の問題は、マルチキャストグループとソースの発見です（[MULTRANS-PS]のセクション3.4を参照）。
o For an IPv6-only receiver requesting multicast content generated by an IPv4-only source:
o IPv4のみのソースによって生成されたマルチキャストコンテンツを要求するIPv6のみの受信者の場合：
* An ALG is required to help the IPv6 receiver select the appropriate IP address when only the IPv4 address is advertised (e.g., using SDP). Otherwise, access to the IPv4 multicast content cannot be offered to the IPv6 receiver. The ALG may be located downstream of the receiver. As such, the ALG does not know in advance whether the receiver is dual-stack or IPv6-only. The ALG may be tuned to insert both the original IPv4 address and the corresponding IPv6 multicast address using, for instance, the ALTC SDP attribute.
* ALGは、IPv4アドレスのみがアドバタイズされる場合（SDPを使用する場合など）にIPv6レシーバーが適切なIPアドレスを選択できるようにするために必要です。そうしないと、IPv4マルチキャストコンテンツへのアクセスをIPv6レシーバーに提供できません。 ALGはレシーバーの下流に配置できます。そのため、ALGは、レシーバーがデュアルスタックかIPv6のみかを事前に知りません。 ALGは、たとえばALTC SDP属性を使用して、元のIPv4アドレスと対応するIPv6マルチキャストアドレスの両方を挿入するように調整できます。
* To avoid involving an ALG in the path, an IPv4-only source can advertise both its IPv4 address and its IPv4-embedded IPv6 multicast address [ADDR-FORMAT] using, for instance, the ALTC SDP attribute.
* パスにALGが含まれないようにするために、IPv4のみのソースは、たとえば、ALTC SDP属性を使用して、IPv4アドレスとIPv4埋め込みIPv6マルチキャストアドレス[ADDR-FORMAT]の両方を通知できます。
o For a dual-stack source sending its multicast content over IPv4 and IPv6, both IPv4 and IPv6 addresses need to be inserted in the SDP part. A means (e.g., ALTC) is needed for this purpose.
o IPv4およびIPv6を介してマルチキャストコンテンツを送信するデュアルスタックソースの場合、IPv4アドレスとIPv6アドレスの両方をSDP部分に挿入する必要があります。この目的のために手段（ALTCなど）が必要です。
Some service providers are in the process of enabling DS-Lite [RFC6333] as a means to continue delivering IPv4 services to their customers. To avoiding crossing four levels of NAT when establishing a media session (two NATs in the DS-Lite Address Family Transition Router (AFTR) and two NATs in the DBE), it is recommended to enable IPv6 functions in some SBEs/DBEs. Then, DS-Lite AFTRs will not be crossed for DS-Lite serviced customers if their UA is IPv6-enabled:
一部のサービスプロバイダーは、顧客にIPv4サービスを提供し続ける手段としてDS-Lite [RFC6333]を有効にするプロセスにあります。メディアセッションを確立するときに4レベルのNATを超えないようにするために（DS-Liteアドレスファミリトランジションルーター（AFTR）の2つのNATとDBEの2つのNAT）、一部のSBE / DBEでIPv6機能を有効にすることをお勧めします。次に、UAがIPv6に対応している場合、DS-Liteのサービスを利用する顧客はDS-Lite AFTRを通過しません。
o For a SIP UA embedded in the CPE, this is easy to implement since the SIP UA [RFC3261] can be tuned to behave as an IPv6-only UA when DS-Lite is enabled. No ALTC is required for this use case. o For SIP UAs located behind the CPE, a solution to indicate both IPv4 and IPv6 (e.g., ALTC) is required in order to avoid crossing the DS-Lite CGN.
o CPEに埋め込まれたSIP UAの場合、DS-Liteが有効になっているときにSIP UA [RFC3261]をIPv6専用UAとして動作するように調整できるため、これは実装が簡単です。この使用例では、ALTCは必要ありません。 o CPEの背後にあるSIP UAの場合、DS-Lite CGNの交差を回避するために、IPv4とIPv6の両方を示すソリューション（ALTCなど）が必要です。
A basic solution to deliver SIP-based services using an IPv4-only core service platform to an IPv6-enabled UA is to enable the IPv4/IPv6 interworking function in the SBE/DBE. Signaling and media between two SBEs and DBEs is maintained over IPv4. IPv6 is used between an IPv6-enabled UA and an SBE/DBE.
IPv4のみのコアサービスプラットフォームを使用してSIPベースのサービスをIPv6対応のUAに配信する基本的なソリューションは、SBE / DBEでIPv4 / IPv6インターワーキング機能を有効にすることです。 2つのSBEとDBE間のシグナリングとメディアは、IPv4を介して維持されます。 IPv6は、IPv6対応のUAとSBE / DBEの間で使用されます。
Figure 3 shows the results of session establishment between UAs. In this scenario, the IPv4/IPv6 interworking function is invoked even when both involved UAs are IPv6-enabled.
図3は、UA間のセッション確立の結果を示しています。このシナリオでは、関係する両方のUAがIPv6対応である場合でも、IPv4 / IPv6インターワーキング機能が呼び出されます。
+----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| | |<-------+
|IPv6 +-----------+ +-----------+ IPv4|
| SIP SIP|
+----+ | +-----------+ +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE |IPv4 RTP| DBE |IPv4 RTP+-|IPv4|
| UA |<-------->|IPv4/v6 IWF|<------>| |<-------->| UA |
+----+ +-----------+ +-----------+ +----+
+----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv6|
| SIP SIP|
+----+ | +-----------+ +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE |IPv4 RTP| DBE |IPv6 RTP+-|IPv6|
| UA |<-------->|IPv4/v6 IWF|<------>|IPv4/v6 IWF|<-------->| UA |
+----+ +-----------+ +-----------+ +----+
Figure 3: Basic Scenario
図3：基本的なシナリオ
It may be valuable for service providers to consider solutions that avoid redundant IPv4/IPv6 NATs and that avoid involving several DBEs.
サービスプロバイダーにとって、冗長なIPv4 / IPv6 NATを回避し、複数のDBEの関与を回避するソリューションを検討することは価値があるかもしれません。
A solution to indicate both IPv4 and IPv4 addresses is required for service providers that want the following:
以下を必要とするサービスプロバイダーには、IPv4アドレスとIPv4アドレスの両方を示すソリューションが必要です。
1. A means to promote the invocation of IPv6 transfer capabilities that can be enabled, while no parsing errors are experienced by core service legacy nodes. 2. To optimize the cost related to IPv4-IPv6 translation licenses. 3. To reduce the dual-stack lifetime. 4. To maintain an IPv4-only core. 5. To have a set of SBEs/DBEs that are IPv6-enabled.
1. コアサービスのレガシーノードで解析エラーが発生することなく、有効にできるIPv6転送機能の呼び出しを促進する手段。 2. IPv4-IPv6変換ライセンスに関連するコストを最適化する。 3.デュアルスタックの寿命を縮めるため。 4. IPv4のみのコアを維持します。 5. IPv6対応のSBE / DBEのセットを持つ。
This section provides an overview of the procedure to avoid IPv4/IPv6 interworking.
このセクションでは、IPv4 / IPv6インターワーキングを回避するための手順の概要を説明します。
When an SBE receives an INVITE, it instantiates in its DBE an IPv6-IPv6 context and an IPv6-IPv4 context. Both an IPv6 address and an IPv4 address are returned, together with other information such as port numbers. The SBE builds an SDP offer, including both the IPv4 and IPv6-related information using the "altc" attribute. IPv6 is indicated as the preferred connectivity type; see Figure 4.
SBEがINVITEを受信すると、DBEでIPv6-IPv6コンテキストとIPv6-IPv4コンテキストをインスタンス化します。 IPv6アドレスとIPv4アドレスの両方が、ポート番号などの他の情報とともに返されます。 SBEは、「altc」属性を使用してIPv4とIPv6の両方に関連する情報を含むSDPオファーを作成します。 IPv6は優先接続タイプとして示されています。図4を参照してください。
o=- 25678 753849 IN IP4 192.0.2.2
c=IN IP4 192.0.2.2
m=audio 12340 RTP/AVP 0 8
a=altc:1 IP6 2001:db8::2 6000
a=altc:2 IP4 192.0.2.2 12340
Figure 4: SDP Offer Updated by the SBE
図4：SBEによって更新されたSDPオファー
The request is then forwarded to the core SPF, which, in turn, forwards it to the terminating SBE.
次に、要求はコアSPFに転送され、次にコアSPFがそれを終端SBEに転送します。
o If this SBE is a legacy one, then it will ignore "altc" attributes and use the "c=" line.
o このSBEがレガシーの場合、「altc」属性を無視して「c =」行を使用します。
o If the terminating SBE is IPv6-enabled:
o 終端SBEがIPv6対応である場合：
* If the called UA is IPv4 only, then an IPv6-IPv4 context is created in the corresponding DBE.
* 呼び出されたUAがIPv4のみの場合、対応するDBEにIPv6-IPv4コンテキストが作成されます。
* If the called UA is IPv6-enabled, then an IPv6-IPv6 context is created in the corresponding DBE.
* 呼び出されたUAがIPv6対応である場合、対応するDBEにIPv6-IPv6コンテキストが作成されます。
Figure 5 shows the results of the procedure when placing a session between an IPv4 and IPv6 UAs, while Figure 6 shows the results of establishing a session between two IPv6-enabled UAs. The result is still not optimal since redundant NAT66 is required (Appendix A.3.4).
図5は、IPv4とIPv6 UAの間にセッションを配置するときの手順の結果を示し、図6は、2つのIPv6対応UAの間にセッションを確立した結果を示しています。冗長なNAT66が必要なため、結果は依然として最適ではありません（付録A.3.4）。
+----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv4|
| SIP SIP|
+----+ | +-----------+ +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE |IPv6 RTP| DBE |IPv4 RTP+-|IPv4|
| UA |<-------->| NAT66 |<------>|IPv4/v6 IWF|<-------->| UA |
+----+ +-----------+ +-----------+ +----+
2001:db8::2
Figure 5: Session Establishment between IPv4 and IPv6 UAs
図5：IPv4 UAとIPv6 UA間のセッション確立
+----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv6|
| SIP SIP|
+----+ | +-----------+ +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE |IPv6 RTP| DBE |IPv6 RTP+-|IPv6|
| UA |<-------->| NAT66 |<------>| NAT66 |<-------->| UA |
+----+ +-----------+ +-----------+ +----+
2001:db8::2
Figure 6: Session Establishment between IPv6 UAs
図6：IPv6 UA間のセッション確立
For service providers wanting to involve only one DBE in the media path when not all SBEs/DBEs and UAs are IPv6-enabled, a means to indicate both IPv4 and IPv6 addresses without inducing session failures is required. This section proposes an example procedure using the "altc" attribute.
すべてのSBE / DBEとUAがIPv6対応ではない場合に、メディアパスにDBEを1つだけ含めたいサービスプロバイダーの場合、セッション障害を引き起こさずにIPv4アドレスとIPv6アドレスの両方を示す手段が必要です。このセクションでは、「altc」属性を使用した手順の例を提案します。
When the originating SBE receives an INVITE from an IPv6-enabled UA, it instantiates in its DBE an IPv6-IPv6 context and an IPv6-IPv4 context. Both an IPv6 address and an IPv4 address are returned, together with other information, such as port numbers. The SBE builds an SDP offer, including both IPv4 and IPv6-related information using the "altc" attribute (Figure 7). IPv6 is indicated as preferred connectivity type.
元のSBEは、IPv6対応のUAからINVITEを受信すると、そのDBEでIPv6-IPv6コンテキストとIPv6-IPv4コンテキストをインスタンス化します。 IPv6アドレスとIPv4アドレスの両方が、ポート番号などの他の情報とともに返されます。 SBEは、「altc」属性を使用して、IPv4とIPv6の両方に関連する情報を含むSDPオファーを構築します（図7）。 IPv6は優先接続タイプとして示されています。
o=- 25678 753849 IN IP4 192.0.2.2
c=IN IP4 192.0.2.2
m=audio 12340 RTP/AVP 0 8
a=altc:1 IP6 2001:db8::2 6000
a=altc:2 IP4 192.0.2.2 12340
Figure 7: SDP Offer Updated by the SBE
図7：SBEによって更新されたSDPオファー
The request is then forwarded to the core SPF, which, in turn, forwards it to the terminating SBE:
次に、要求はコアSPFに転送され、次にコアSPFがそれを終端SBEに転送します。
o If the destination UA is IPv6 or reachable with a public IPv4 address, the SBEs only forwards the request without altering the SDP offer. No parsing error is experienced by core service nodes since ALTC is backward compatible.
o 宛先UAがIPv6またはパブリックIPv4アドレスで到達可能な場合、SBEは要求を転送するだけで、SDPオファーは変更されません。 ALTCには下位互換性があるため、コアサービスノードで解析エラーが発生することはありません。
o If the terminating SBE does not support ALTC, it will ignore this attribute and use the legacy procedure.
o 終了側のSBEがALTCをサポートしていない場合、この属性は無視され、従来の手順が使用されます。
As a consequence, only one DBE is maintained in the path when one of the involved parties is IPv6-enabled. Figure 8 shows the overall procedure when the involved UAs are IPv6-enabled.
結果として、関係者の1つがIPv6対応である場合、パスで維持されるDBEは1つだけです。図8は、関連するUAがIPv6対応である場合の全体的な手順を示しています。
+----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv6|
| SIP SIP|
+----+ | +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE | IPv6 RTP +-|IPv6|
| UA |<-------->| NAT66 |<----------------------------->| UA |
+----+ +-----------+ +----+
2001:db8::1 2001:db8::2
Figure 8: DBE Bypass Overview
図8：DBEバイパスの概要
The main advantages of such a solution are as follows:
このようなソリューションの主な利点は次のとおりです。
o DBE resources are optimized. o No redundant NAT is maintained in the path when IPv6-enabled UAs are involved. o End-to-end delay is optimized. o The robustness of the service is optimized since the delivery of the service relies on fewer nodes. o The signaling path is also optimized since no communication between the SBE and DBE at the terminating side is required for some sessions. (That communication would be through the Service Policy Decision Function (SPDF) in a Telecoms and Internet converged Services and Protocols for Advanced Networks/IP Multimedia Subsystem (TISPAN/IMS) context.)
o DBEリソースは最適化されています。 o IPv6対応のUAが関与している場合、冗長NATはパスで維持されません。 oエンドツーエンドの遅延が最適化されています。 oサービスの配信に依存するノードが少ないため、サービスの堅牢性が最適化されます。 o一部のセッションでは、終端側のSBEとDBE間の通信が必要ないため、シグナリングパスも最適化されます。 （その通信は、高度なネットワーク/ IPマルチメディアサブシステム（TISPAN / IMS）コンテキスト用のテレコムおよびインターネット統合サービスおよびプロトコルのサービスポリシー決定機能（SPDF）を介して行われます。）
For service providers wanting to allow direct IPv6 communications between IPv6-enabled UAs, when not all SBEs/DBEs and UAs are IPv6-enabled, a means to indicate both the IPv4 and IPv6 addresses without inducing session failures is required. Below is an example of a proposed procedure using the "altc" attribute.
すべてのSBE / DBEとUAがIPv6対応ではない場合に、IPv6対応のUA間の直接IPv6通信を許可するサービスプロバイダーの場合、セッションエラーを引き起こさずにIPv4アドレスとIPv6アドレスの両方を示す手段が必要です。以下は、「altc」属性を使用する提案された手順の例です。
At the SBE originating side, when the SBE receives an INVITE from the calling IPv6 UA (Figure 9), it uses ALTC to indicate two IP addresses:
SBE発信側では、SBEが呼び出し側のIPv6 UAからINVITEを受信すると（図9）、ALTCを使用して2つのIPアドレスを示します。
1. An IPv4 address belonging to its controlled DBE. 2. The same IPv6 address and port as received in the initial offer made by the calling IPv6.
1. 制御されたDBEに属するIPv4アドレス。 2.呼び出し側IPv6が最初に提供したものと同じIPv6アドレスとポート。
Figure 9 shows an excerpted example of the SDP offer of the calling UA, and Figure 10 shows an excerpted example of the updated SDP offer generated by the originating SBE.
図9は、呼び出し元UAのSDPオファーの抜粋例を示し、図10は、発信元のSBEによって生成された更新済みSDPオファーの抜粋例を示しています。
o=- 25678 753849 IN IP6 2001:db8::1
c=IN IP6 2001:db8::1
m=audio 6000 RTP/AVP 0 8
Figure 9: SDP Offer of the Calling UA
図9：呼び出し元UAのSDPオファー
o=- 25678 753849 IN IP4 192.0.2.2
c=IN IP4 192.0.2.2
m=audio 12340 RTP/AVP 0 8
a=altc:1 IP6 2001:db8::1 6000
a=altc:2 IP4 192.0.2.2 12340
Figure 10: SDP Offer Updated by the SBE
図10：SBEによって更新されたSDPオファー
The INVITE message will be routed appropriately to the destination SBE:
INVITEメッセージは、宛先SBEに適切にルーティングされます。
1. If the SBE is a legacy device (i.e., IPv4-only), it will ignore IPv6 addresses and will contact its DBE to instantiate an IPv4-IPv4 context. 2. If the SBE is IPv6-enabled, it will only forward the INVITE to the address of contact of the called party:
1. SBEがレガシーデバイスの場合（つまり、IPv4のみ）、IPv6アドレスを無視し、DBEに連絡してIPv4-IPv4コンテキストをインスタンス化します。 2. SBEがIPv6対応の場合、SVはINVITEを着信側の連絡先アドレスにのみ転送します。
a. If the called party is IPv6-enabled, the communication will be placed using IPv6. As such, no DBE is involved in the data path, as illustrated in Figure 11. b. Otherwise, IPv4 will be used between the originating DBE and the called UA.
a. 着信側がIPv6対応の場合、通信はIPv6を使用して行われます。そのため、図11に示すように、DBEはデータパスに関与しません。それ以外の場合は、発信元のDBEと呼び出されたUAの間でIPv4が使用されます。
+----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv6|
| SIP SIP|
+----+ | | +----+
|IPv6|-+ IPv6 RTP +-|IPv6|
| UA |<---------------------------------------------------->| UA |
+----+ +----+
2001:db8::1
Figure 11: Direct IPv6 Communication
図11：直接IPv6通信
Authors' Addresses
著者のアドレス
Mohamed Boucadair France Telecom Rennes 35000 France
Mohamed Boucadair France Telecom Rennes 35000 France
EMail: mohamed.boucadair@orange.com
Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803 USA
ハドリエルカプランAcmeパケット71サードアベニュー。バーリントン、MA 01803 USA
EMail: hkaplan@acmepacket.com
Robert R Gilman Independent
ロバートRギルマンインディペンデント
EMail: bob_gilman@comcast.net
Simo Veikkolainen Nokia
Simo Veikkolainenノキア
EMail: Simo.Veikkolainen@nokia.com