[要約] RFC 7104は、セッション記述プロトコル（SDP）における重複グループの意味論に関するものであり、重複するメディアストリームをグループ化する方法を提供します。このRFCの目的は、SDPのセッション記述における重複の管理を改善し、ネットワークリソースの効率化を図ることです。
Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 7104 Cisco
Category: Standards Track Y. Cai
ISSN: 2070-1721 Microsoft
H. Ou
Cisco
January 2014
Duplication Grouping Semantics in the Session Description Protocol
セッション記述プロトコルの重複グループ化セマンティクス
Abstract
概要
Packet loss is undesirable for real-time multimedia sessions, but it can occur due to congestion or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework. Grouping semantics at the Synchronization Source (SSRC) level are also defined in this document for RTP streams using SSRC multiplexing.
パケット損失は、リアルタイムのマルチメディアセッションには望ましくありませんが、輻輳やその他の計画外のネットワーク停止が原因で発生する可能性があります。これは特に、IPマルチキャストネットワークに当てはまります。IPマルチキャストネットワークでは、パケット損失パターンがレシーバー間で大きく異なる可能性があります。すべてのレシーバーに無制限の遅延を発生させずにパケット損失から回復するために使用できる1つの手法は、パケットを複製して、別々の冗長ストリームで送信することです。このドキュメントでは、Session Description Protocol（SDP）で冗長ストリームをグループ化するためのセマンティクスを定義しています。このドキュメントで定義されているセマンティクスは、SDPグループ化フレームワークで使用されます。このドキュメントでは、SSRC多重化を使用したRTPストリームについて、同期ソース（SSRC）レベルでのグループ化セマンティクスも定義されています。
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/rfc7104.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7104で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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. Requirements Notation ...........................................3
3. Duplication Grouping ............................................3
3.1. "DUP" Grouping Semantics ...................................3
3.2. Duplication Grouping for SSRC-Multiplexed RTP Streams ......3
3.3. SDP Offer/Answer Model Considerations ......................4
4. SDP Examples ....................................................5
4.1. Separate Source Addresses ..................................5
4.2. Separate Destination Addresses .............................6
4.3. Temporal Redundancy ........................................7
5. Security Considerations .........................................7
6. IANA Considerations .............................................8
7. Acknowledgments .................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................9
The Real-time Transport Protocol (RTP) [RFC3550] is widely used today for delivering IPTV traffic and other real-time multimedia sessions. Many of these applications support very large numbers of receivers and rely on intra-domain UDP/IP multicast for efficient distribution of traffic within the network.
リアルタイムトランスポートプロトコル（RTP）[RFC3550]は、IPTVトラフィックやその他のリアルタイムマルチメディアセッションを配信するために今日広く使用されています。これらのアプリケーションの多くは、非常に多数のレシーバーをサポートし、ネットワーク内のトラフィックを効率的に配信するためにドメイン内UDP / IPマルチキャストに依存しています。
While this combination has proved successful, there does exist a weakness. As [RFC2354] noted, packet loss is not avoidable, even in a carefully managed network. This loss might be due to congestion; it might also be a result of an unplanned outage caused by a flapping link, a link or interface failure, a software bug, or a maintenance person accidentally cutting the wrong fiber. Since UDP/IP flows do not provide any means for detecting loss and retransmitting packets, it is left up to the RTP layer and the applications to detect, and recover from, packet loss.
この組み合わせは成功していることが証明されていますが、弱点もあります。 [RFC2354]が述べたように、慎重に管理されたネットワークであっても、パケット損失は避けられません。この損失は、輻輳が原因である可能性があります。また、フラッピングリンク、リンクまたはインターフェイスの障害、ソフトウェアのバグ、または保守担当者が誤って間違ったファイバを切断したことが原因で、計画外の停止が発生した可能性もあります。 UDP / IPフローは、損失を検出してパケットを再送信する手段を提供しないため、RTPレイヤーとアプリケーションに任され、パケット損失を検出して回復します。
One technique to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. Variations on this idea have been implemented and deployed today [IC2011]. [RTP-DUP] explains how duplication can be achieved for RTP streams without breaking the RTP and RTP Control Protocol (RTCP) functionality. In this document, we describe the semantics needed in the Session Description Protocol (SDP) [RFC4566] to support this technique.
すべてのレシーバーに無制限の遅延を発生させずにパケット損失から回復する1つの手法は、パケットを複製して、別々の冗長ストリームで送信することです。このアイデアのバリエーションが今日実装され、展開されています[IC2011]。 [RTP-DUP]では、RTPおよびRTP制御プロトコル（RTCP）機能を損なうことなく、RTPストリームの複製を実現する方法について説明しています。このドキュメントでは、この手法をサポートするためにセッション記述プロトコル（SDP）[RFC4566]で必要なセマンティクスについて説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
Each "a=group" line is used to indicate an association relationship between the redundant streams. The streams included in one "a=group" line are called a "Duplication Group".
各「a = group」行は、冗長ストリーム間の関連関係を示すために使用されます。 1つの「a = group」行に含まれるストリームは、「複製グループ」と呼ばれます。
Using the SDP Grouping Framework in [RFC5888], this document defines "DUP" as the grouping semantics for redundant streams.
このドキュメントでは、[RFC5888]のSDPグループ化フレームワークを使用して、「DUP」を冗長ストリームのグループ化セマンティクスとして定義しています。
The "a=group:DUP" semantics MUST be used to group the redundant streams, except when the streams are specified in the same media description, i.e., in the same "m" line (see Section 3.2). In an "a=group:DUP" line, the order of the listed redundant streams does not strictly indicate the order of transmission, although it is RECOMMENDED that the stream listed first be sent first, with the other stream(s) being the (time-delayed) duplicate(s).
「a = group：DUP」セマンティクスを使用して冗長ストリームをグループ化する必要があります。ただし、ストリームが同じメディア記述、つまり同じ「m」行で指定されている場合を除きます（セクション3.2を参照）。 「a = group：DUP」行では、リストされた冗長ストリームの順序は厳密に送信の順序を示していませんが、最初にリストされたストリームが最初に送信され、他のストリームは（時間遅れ）重複。
[RFC5576] defines an SDP media-level attribute, called "ssrc-group", for grouping the RTP streams that are SSRC multiplexed and carried in the same RTP session. The grouping is based on the SSRC identifiers. Since SSRC-multiplexed RTP streams are defined in the same "m" line, the "group" attribute cannot be used.
[RFC5576]は、SSRC多重化され、同じRTPセッションで伝送されるRTPストリームをグループ化するために、「ssrc-group」と呼ばれるSDPメディアレベル属性を定義します。グループ化は、SSRC識別子に基づいています。 SSRC多重化RTPストリームは同じ "m"行で定義されているため、 "group"属性は使用できません。
This section explains how duplication is used with SSRC-multiplexed streams using the "ssrc-group" attribute [RFC5576].
このセクションでは、「ssrc-group」属性を使用してSSRC多重化ストリームで複製を使用する方法について説明します[RFC5576]。
The semantics of "DUP" for the "ssrc-group" attribute are the same as the one defined for the "group" attribute, except that the SSRC identifiers are used to designate the duplication grouping associations: a=ssrc-group:DUP *(SP ssrc-id) [RFC5576]. As above, while in an "a=ssrc-group:DUP" line, the order of the listed redundant streams does not necessarily indicate the order of transmission, but it is RECOMMENDED that the stream listed first be sent first, with the other stream(s) being the (time-delayed) duplicate(s).
「ssrc-group」属性の「DUP」のセマンティクスは、「group」属性に定義されたものと同じですが、SSRC識別子を使用して重複グループ化の関連付けを指定します。a= ssrc-group：DUP * （SP ssrc-id）[RFC5576]。上記のように、「a = ssrc-group：DUP」行では、リストされた冗長ストリームの順序は必ずしも送信の順序を示しているわけではありませんが、最初にリストされたストリームが最初に送信され、他のストリームとともに送信されることをお勧めします（s）は（時間遅延された）重複です。
When offering duplication grouping using SDP in an offer/answer model [RFC3264], the following considerations apply.
オファー/アンサーモデル[RFC3264]でSDPを使用して複製グループ化を提供する場合、次の考慮事項が適用されます。
A node that is receiving an offer from a sender may or may not understand line grouping. It is also possible that the node understands line grouping but does not understand the "DUP" semantics. From the viewpoint of the sender of the offer, these cases are indistinguishable.
送信者からオファーを受信しているノードは、回線のグループ化を理解する場合と理解しない場合があります。ノードが行のグループ化を理解しているが、「DUP」セマンティクスを理解していない可能性もあります。オファーの送信者の観点からは、これらのケースは区別できません。
When a node is offered a session with the "DUP" grouping semantics but it does not support line grouping or the duplication grouping semantics, as per [RFC5888], the node responds to the offer either (1) with an answer that omits the grouping attribute or (2) with a refusal to the request (e.g., "488 Not Acceptable Here" or "606 Not Acceptable in SIP").
[RFC5888]のように、ノードに「DUP」グループ化セマンティクスのセッションが提供されているが、ライングループ化または複製グループ化セマンティクスをサポートしていない場合、ノードはオファーに応答します（1）グループ化を省略した応答属性または（2）要求に対する拒否（たとえば、「488 Not Acceptable Here」または「606 Not Acceptable in SIP」）。
In the first case, the original sender of the offer must send a new offer without any duplication grouping. In the second case, if the sender of the offer still wishes to establish the session, it should retry the request with an offer without the duplication grouping. This behavior is specified in [RFC5888].
最初のケースでは、オファーの元の送信者は、重複のグループ化なしで新しいオファーを送信する必要があります。 2番目のケースでは、オファーの送信者が引き続きセッションを確立したい場合、複製のグループ化なしでオファーを使用してリクエストを再試行する必要があります。この動作は[RFC5888]で指定されています。
In this example, the redundant streams use the same IP destination address (232.252.0.1), but they are sourced from different addresses (198.51.100.1 and 198.51.100.2). Thus, the receiving host needs to join both source-specific multicast (SSM) sessions separately.
この例では、冗長ストリームは同じIP宛先アドレス（232.252.0.1）を使用していますが、それらは異なるアドレス（198.51.100.1と198.51.100.2）から送信されています。したがって、受信ホストは両方の送信元固有マルチキャスト（SSM）セッションに個別に参加する必要があります。
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=DUP Grouping Semantics
t=0 0
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 198.51.100.2
a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1@example.com
a=ssrc:1010 cname:ch1@example.com
a=ssrc-group:DUP 1000 1010
a=mid:Ch1
Note that in actual use, SSRC values, which are random 32-bit numbers, can be much larger than the ones shown in this example. Also, note that this SDP description does not use the "duplication-delay" attribute (defined in [DELAYED-DUP]) since the sender does not apply any delay between the redundant streams upon transmission. Alternatively, one MAY explicitly insert an "a=duplication-delay:0" line before the "a=mid:Ch1" line for informational purposes.
実際の使用では、ランダムな32ビットの数値であるSSRC値は、この例に示されている値よりはるかに大きくなる可能性があることに注意してください。また、送信者は送信時に冗長ストリーム間に遅延を適用しないため、このSDPの説明では[duplication-delay]属性（[DELAYED-DUP]で定義）を使用しないことに注意してください。または、情報提供のために、「a = mid：Ch1」行の前に「a = duplication-delay：0」行を明示的に挿入してもよい（MAY）。
In this example, the redundant streams have different IP destination addresses. The example shows the same UDP port number and IP source address for each stream, but either or both could have been different for the two streams.
この例では、冗長ストリームに異なるIP宛先アドレスがあります。この例では、各ストリームの同じUDPポート番号とIP送信元アドレスを示していますが、2つのストリームでどちらかまたは両方が異なっている可能性があります。
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=DUP Grouping Semantics
t=0 0
a=group:DUP S1a S1b
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=mid:S1a
m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:101 MP2T/90000
a=mid:S1b
Optionally, one could be more explicit and insert an "a=duplication-delay:0" line before the first "m" line.
必要に応じて、より明示的に、最初の "m"行の前に "a = duplication-delay：0"行を挿入することもできます。
In this example, the redundant streams have the same IP source and destination addresses (i.e., they are transmitted in the same SSM session). Due to the same source and destination addresses, the packets in both streams will be routed over the same path. To provide resiliency against packet loss, the duplicate of an original packet is transmitted 50 milliseconds (ms) later as indicated by the "duplication-delay" attribute (defined in [DELAYED-DUP]).
この例では、冗長ストリームのIP送信元アドレスと宛先アドレスは同じです（つまり、同じSSMセッションで送信されます）。送信元アドレスと宛先アドレスが同じであるため、両方のストリームのパケットは同じパスを介してルーティングされます。パケット損失に対する回復力を提供するために、「duplication-delay」属性（[DELAYED-DUP]で定義）で示されるように、元のパケットの複製が50ミリ秒（ms）後に送信されます。
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication
t=0 0
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1a@example.com
a=ssrc:1010 cname:ch1a@example.com
a=ssrc-group:DUP 1000 1010
a=duplication-delay:50
a=mid:Ch1
In general, the security considerations of [RFC4566] apply to this document as well.
一般に、[RFC4566]のセキュリティに関する考慮事項は、このドキュメントにも適用されます。
There is a weak threat for the receiver that the duplication grouping can be modified to indicate relationships that do not exist. Such attacks might result in failure of the duplication mechanisms and/or mishandling of the media streams by the receivers.
複製グループ化を変更して、存在しない関係を示すことができるという弱点が受信者にあります。このような攻撃は、複製メカニズムの失敗や受信者によるメディアストリームの誤処理につながる可能性があります。
In order to avoid attacks of this sort, the SDP description needs to be integrity protected and provided with source authentication. This can, for example, be achieved on an end-to-end basis using S/MIME [RFC5652] [RFC5751] when the SDP is used in a signaling packet using MIME types (application/sdp). Alternatively, HTTPS [RFC2818] or the authentication method in the Session Announcement Protocol (SAP) [RFC2974] could be used as well. As for the confidentiality, if it is desired, it can be useful to use a secure, encrypted transport method to carry the SDP description.
この種の攻撃を回避するには、SDP記述を整合性保護し、ソース認証を提供する必要があります。これは、たとえば、S / MIME [RFC5652] [RFC5751]を使用してエンドツーエンドで、MIMEタイプ（application / sdp）を使用するシグナリングパケットでSDPを使用する場合に実現できます。あるいは、HTTPS [RFC2818]またはSession Announcement Protocol（SAP）[RFC2974]の認証方法も使用できます。機密性については、必要に応じて、安全で暗号化された転送方法を使用してSDP記述を運ぶと便利です。
This document registers the following semantics with IANA in the "Semantics for the "group" SDP Attribute" subregistry (under the "Session Description Protocol (SDP) Parameters" registry:
このドキュメントでは、「「グループ」SDP属性のセマンティクス」サブレジストリ（「セッション記述プロトコル（SDP）パラメータ」レジストリの下）で、次のセマンティクスをIANAに登録しています。
Semantics Token Reference
------------------------------------- ------ ---------
Duplication DUP [RFC7104]
This document also registers the following semantics with IANA in the "Semantics for the "ssrc-group" SDP Attribute" subregistry under the "Session Description Protocol (SDP) Parameters" registry:
このドキュメントは、「Session Description Protocol（SDP）Parameters」レジストリの下の「ssrc-group SDP Attributeのセマンティクス」サブレジストリの次のセマンティクスをIANAに登録します。
Token Semantics Reference
------- ----------------------------- ---------
DUP Duplication [RFC7104]
The authors would like to thank Colin Perkins, Bill Ver Steeg, Dave Oran, and Toerless Eckert for their input and suggestions.
著者は、彼らの意見や提案をしてくれたColin Perkins、Bill Ver Steeg、Dave Oran、Toerless Eckertに感謝したいと思います。
[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月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「オファー/アンサーモデルとセッション記述プロトコル（SDP）」、RFC 3264、2002年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[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月。
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009.
[RFC5576] Lennox、J.、Ott、J。、およびT. Schierl、「Session Description Protocol（SDP）のソース固有のメディア属性」、RFC 5576、2009年6月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888] Camarillo、G。およびH. Schulzrinne、「Session Description Protocol（SDP）Grouping Framework」、RFC 5888、2010年6月。
[DELAYED-DUP] Begen, A., Cai, Y., and H. Ou, "Delayed Duplication Attribute in the Session Description Protocol", Work in Progress, December 2013.
[DELAYED-DUP] Begen、A.、Cai、Y。、およびH. Ou、「Session Description Protocolの遅延複製属性」、Work in Progress、2013年12月。
[IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils, "Toward Lossless Video Transport, IEEE Internet Computing, vol. 15/6, pp. 48-57", November 2011.
[IC2011] Evans、J.、Begen、A.、Greengrass、J.、およびC. Filsfils、「Total Lossless Video Transport、IEEE Internet Computing、vol。15/6、pp。48-57」、2011年11月。
[RFC2354] Perkins, C. and O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998.
[RFC2354]パーキンス、C。およびO.ホドソン、「ストリーミングメディアの修復オプション」、RFC 2354、1998年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、2000年5月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「Session Announcement Protocol」、RFC 2974、2000年10月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、2009年9月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月。
[RTP-DUP] Begen, A. and C. Perkins, "Duplicating RTP Streams", Work in Progress, October 2013.
[RTP-DUP] Begen、A。およびC. Perkins、「Duplicating RTP Streams」、Work in Progress、2013年10月。
Authors' Addresses
著者のアドレス
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
Ali Begen Cisco 181 Bay Streetトロント、ON M5J 2T3カナダ
EMail: abegen@cisco.com
Yiqun Cai Microsoft 1065 La Avenida Mountain View, CA 94043 USA
Y IグループCAI Microsoft 1065 LA av EN IDAマウンテンビュー、CA 94043米国
EMail: yiqunc@microsoft.com
Heidi Ou Cisco 170 W. Tasman Dr. San Jose, CA 95134 USA
Heidi Ou Cisco 170 W. Tasman Dr. San Jose、CA 95134 USA
EMail: hou@cisco.com