[要約] RFC 5432は、SDPでのQoSメカニズムの選択に関するガイドラインです。このRFCの目的は、SDPを使用してQoSメカニズムを選択する際のベストプラクティスを提供することです。
Network Working Group J. Polk
Request for Comments: 5432 S. Dhesikan
Category: Standards Track Cisco Systems
G. Camarillo
Ericsson
March 2009
Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)
サービス品質（QoS）セッション説明プロトコル（SDP）のメカニズムの選択
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
The offer/answer model for the Session Description Protocol (SDP) assumes that endpoints somehow establish the Quality of Service (QoS) required for the media streams they establish. Endpoints in closed environments typically agree out-of-band (e.g., using configuration information) regarding which QoS mechanism to use. However, on the Internet, there is more than one QoS service available. Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use for a particular media stream. This document defines such a mechanism.
セッション説明プロトコル（SDP）のオファー/回答モデルは、エンドポイントが何らかの形で確立するメディアストリームに必要なサービス品質（QO）を確立することを前提としています。閉じた環境のエンドポイントは、通常、どのQoSメカニズムを使用するかについて、帯域外（たとえば、構成情報を使用するなど）に同意します。ただし、インターネットでは、複数のQoSサービスが利用可能です。その結果、特定のメディアストリームに使用するQoSメカニズムを交渉するメカニズムが必要です。このドキュメントは、そのようなメカニズムを定義しています。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. SDP Attributes Definition .......................................3
4. Offer/Answer Behavior ...........................................4
4.1. Offerer Behavior ...........................................4
4.2. Answerer Behavior ..........................................4
4.3. Resource Reservation .......................................5
4.4. Subsequent Offer/Answer Exchanges ..........................5
5. Example .........................................................5
6. IANA Considerations .............................................6
6.1. Registration of the SDP 'qos-mech-send' Attribute ..........6
6.2. Registration of the SDP 'qos-mech-recv' Attribute ..........6
6.3. Registry for QoS Mechanism Tokens ..........................7
7. Security Considerations .........................................7
8. Acknowledgements ................................................7
9. References ......................................................8
9.1. Normative References .......................................8
9.2. Informative References .....................................8
The offer/answer model [RFC3264] for SDP [RFC4566] does not provide any mechanism for endpoints to negotiate the QoS mechanism to be used for a particular media stream. Even when QoS preconditions [RFC3312] are used, the choice of the QoS mechanism is left unspecified and is up to the endpoints.
SDP [RFC4566]のオファー/回答モデル[RFC3264]は、特定のメディアストリームに使用されるQOSメカニズムを交渉するエンドポイントのメカニズムを提供しません。QoSの前提条件[RFC3312]を使用している場合でも、QOSメカニズムの選択は特定されていないままであり、エンドポイントに至ります。
Endpoints that support more than one QoS mechanism need a way to negotiate which one to use for a particular media stream. Examples of QoS mechanisms are RSVP (Resource Reservation Protocol) [RFC2205] and NSIS (Next Steps in Signaling) [QoS-NSLP].
複数のQoSメカニズムをサポートするエンドポイントには、特定のメディアストリームに使用するものを交渉する方法が必要です。QoSメカニズムの例は、RSVP（リソース予約プロトコル）[RFC2205]およびNSIS（シグナルの次のステップ）[QOS-NSLP]です。
This document defines a mechanism that allows endpoints to negotiate the QoS mechanism to be used for a particular media stream. However, the fact that endpoints agree on a particular QoS mechanism does not imply that that particular mechanism is supported by the network. Discovering which QoS mechanisms are supported at the network layer is out of the scope of this document. In any case, the information the endpoints exchange to negotiate QoS mechanisms, as defined in this document, can be useful for a network operator to resolve a subset of the QoS interoperability problem -- namely, to ensure that a mechanism commonly acceptable to the endpoints is chosen and make it possible to debug potential misconfiguration situations.
このドキュメントは、エンドポイントが特定のメディアストリームに使用されるQoSメカニズムをネゴシエートできるようにするメカニズムを定義します。ただし、エンドポイントが特定のQoSメカニズムに同意するという事実は、その特定のメカニズムがネットワークによってサポートされていることを意味するものではありません。ネットワークレイヤーでどのQoSメカニズムがサポートされているかを発見することは、このドキュメントの範囲外です。いずれにせよ、このドキュメントで定義されているQoSメカニズムを交渉するためのエンドポイントの情報は、ネットワークオペレーターがQoS相互運用性問題のサブセットを解決するために役立ちます。つまり、エンドポイントに一般的に許容できるメカニズムを確保するために選択されており、潜在的な誤解状況をデバッグすることを可能にします。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
This document defines the 'qos-mech-send' and 'qos-mech-recv' session and media-level SDP [RFC4566] attributes. The following is their Augmented Backus-Naur Form (ABNF) [RFC5234] syntax, which is based on the SDP [RFC4566] grammar:
このドキュメントでは、「QoS-Mech-Send」および「QoS-Mech-Recv」セッションとメディアレベルのSDP [RFC4566]属性を定義します。以下は、SDP [RFC4566]グラマーに基づく構文の増強されたバックスノーフォーム（ABNF）[RFC5234]構文です。
attribute =/ qos-mech-send-attr
attribute =/ qos-mech-recv-attr
qos-mech-send-attr = "qos-mech-send" ":"
[[SP] qos-mech *(SP qos-mech)]
qos-mech-recv-attr = "qos-mech-recv" ":"
[[SP] qos-mech *(SP qos-mech)]
qos-mech = "rsvp" / "nsis" / extension-mech
extension-mech = token
The 'qos-mech' token identifies a QoS mechanism that is supported by the entity generating the session description. A token that appears in a 'qos-mech-send' attribute identifies a QoS mechanism that can be used to reserve resources for traffic sent by the entity generating the session description. A token that appears in a 'qos-mech-recv' attribute identifies a QoS mechanism that can be used to reserve resources for traffic received by the entity generating the session description.
「QOS-Mech」トークンは、セッションの説明を生成するエンティティによってサポートされるQOSメカニズムを識別します。「QOS-Mech-Send」属性に表示されるトークンは、セッションの説明を生成するエンティティから送信されるトラフィックのリソースを予約するために使用できるQoSメカニズムを識別します。「QOS-Mech-Recv」属性に表示されるトークンは、セッションの説明を生成するエンティティが受け取ったトラフィックのリソースを予約するために使用できるQoSメカニズムを識別します。
The 'qos-mech-send' and 'qos-mech-recv' attributes are not interdependent; one can be used without the other.
「QOS-Mech-Send」および「Qos-Mech-Recv」属性は相互依存しません。一方はもう一方なしで使用できます。
The following is an example of an 'm' line with 'qos-mech-send' and 'qos-mech-recv' attributes:
以下は、「QOS-Mech-Send」と「QoS-Mech-Recv」属性を備えた「M」行の例です。
m=audio 50000 RTP/AVP 0
a=qos-mech-send: rsvp nsis
a=qos-mech-recv: rsvp nsis
Through the use of the 'qos-mech-send' and 'qos-mech-recv' attributes, an offer/answer exchange allows endpoints to come up with a list of common QoS mechanisms sorted by preference. However, note that endpoints negotiate in which direction QoS is needed using other mechanisms, such as preconditions [RFC3312]. Endpoints may also use other mechanisms to negotiate, if needed, the parameters to use with a given QoS mechanism (e.g., bandwidth to be reserved).
「QOS-Mech-Send」および「QoS-Mech-Recv」属性を使用することにより、オファー/回答交換により、エンドポイントは好みによってソートされた一般的なQoSメカニズムのリストを作成できます。ただし、エンドポイントは、前提条件[RFC3312]などの他のメカニズムを使用してQoSが必要な方向に交渉することに注意してください。エンドポイントは、他のメカニズムを使用して、必要に応じて、特定のQoSメカニズム（予約する帯域幅など）で使用するパラメーターを交渉することもできます。
Offerers include a 'qos-mech-send' attribute with the tokens corresponding to the QoS mechanisms (in order of preference) that are supported in the send direction. Similarly, offerers include a 'qos-mech-recv' attribute with the tokens corresponding to the QoS mechanisms (in order of preference) that are supported in the receive direction.
オファーは、送信方向でサポートされているQoSメカニズム（優先順序で）に対応するトークンを備えた「QOS-Mech-Send」属性を含みます。同様に、オファーは、受信方向でサポートされているQoSメカニズム（優先順序で）に対応するトークンを含む「QoS-Mech-Recv」属性を含みます。
On receiving an offer with a set of tokens in a 'qos-mech-send' attribute, the answerer takes those tokens corresponding to QoS mechanisms that it supports in the receive direction and includes them, in order of preference, in a 'qos-mech-recv' attribute in the answer. On receiving an offer with a set of tokens in a 'qos-mech-recv' attribute, the answerer takes those tokens corresponding to QoS mechanisms that it supports in the send direction and includes them, in order of preference, in a 'qos-mech-send' attribute in the answer.
「QOS-Mech-SEND」属性のトークンのセットを含むオファーを受信すると、回答者は、受信方向でサポートするQoSメカニズムに対応するトークンを取り、それらを好みの順に含めて 'qos-でそれらを含めます。回答のmech-recv '属性。「QOS-Mech-Recv」属性のトークンのセットを含むオファーを受信すると、回答者は、送信方向でサポートし、好みの順に、「QoS-」でそれらを含めるQOSメカニズムに対応するトークンを取ります。mech-send '属性の属性。
When ordering the tokens in a 'qos-mech-send' or a 'qos-mech-recv' attribute by preference, the answerer may take into account its own preferences and those expressed in the offer. However, the exact algorithm to be used to order such token lists is outside the scope of this specification.
「QOS-Mech-Send」または「Qos-Mech-Recv」属性でトークンを優先的に注文する場合、Aswerserは独自の好みとオファーで表現されたものを考慮することができます。ただし、このようなトークンリストを注文するために使用される正確なアルゴリズムは、この仕様の範囲外です。
Note that if the answerer does not have any QoS mechanism in common with the offerer, it will return empty 'qos-mech-send' and 'qos-mech-recv' attributes.
応答者に提供者と共通のQoSメカニズムがない場合、空の「QOS-Mech-Send」および「QOS-Mech-Recv」属性を返すことに注意してください。
Once the offer/answer exchange completes, both offerer and answerer use the token lists in the 'qos-mech-send' and 'qos-mech-recv' attributes of the answer to perform resource reservations. Offerers and answerers SHOULD attempt to use the QoS mechanism with highest priority in each direction first. If an endpoint (the offerer or the answerer) does not succeed in using the mechanism with highest priority in a given direction, it SHOULD attempt to use the next QoS mechanism in order of priority in that direction, and so on.
オファー/回答の交換が完了すると、オファーと応答者の両方が、リソース予約を実行するために、回答の「QoS-Mech-Send」および「QoS-Mech-Recv」属性のトークンリストを使用します。オファーと応答者は、最初に各方向に最優先事項を持つQoSメカニズムを使用しようとする必要があります。エンドポイント（提供者または応答者）が、特定の方向に最優先事項のメカニズムを使用することに成功しない場合、その方向の優先度の順に次のQoSメカニズムを使用しようとする必要があります。
If an endpoint unsuccessfully tries all the common QoS mechanisms for a given direction, the endpoint MAY attempt to use additional QoS mechanisms not supported by the remote endpoint. This is because there may be network entities out of the endpoint's control (e.g., an RSVP proxy) that make those mechanisms work.
エンドポイントが特定の方向のすべての一般的なQOSメカニズムを試みて失敗した場合、エンドポイントはリモートエンドポイントでサポートされていない追加のQoSメカニズムを使用しようとする場合があります。これは、これらのメカニズムを機能させるエンドポイントの制御（たとえば、RSVPプロキシ）からネットワークエンティティが存在する可能性があるためです。
If, during an established session for which the QoS mechanism to be used for a given direction was agreed upon using the mechanism defined in this specification, an endpoint receives a subsequent offer that does not contain the QoS selection attribute corresponding to that direction (i.e., the 'qos-mech-send' or 'qos-mech-recv' attribute is missing), the endpoints SHOULD continue using the same QoS mechanism used up to that moment.
この仕様で定義されているメカニズムを使用して特定の方向に使用されるQOSメカニズムが特定の方向に使用される確立されたセッション中に、エンドポイントは、その方向に対応するQOS選択属性を含むその後のオファーを受け取ります（つまり、「QOS-Mech-Send」または「QOS-Mech-Recv」属性が欠落しています）、エンドポイントは、その瞬間に使用されている同じQoSメカニズムを使用し続ける必要があります。
The following is an offer/answer exchange between two endpoints using the 'qos-mech-send' and 'qos-mech-recv' attributes. Parts of the session descriptions are omitted for clarity purposes.
以下は、「QOS-Mech-Send」と「QoS-Mech-Recv」属性を使用した2つのエンドポイント間のオファー/回答交換です。セッションの説明の一部は、明確な目的で省略されています。
The offerer generates the following session description, listing both RSVP and NSIS for both directions. The offerer would prefer to use RSVP and, thus, includes it before NSIS.
Offererは、次のセッションの説明を生成し、両方の方向にRSVPとNSIの両方をリストします。オファーはRSVPを使用することを好むため、NSISの前にそれを含みます。
m=audio 50000 RTP/AVP 0
a=qos-mech-send: rsvp nsis
a=qos-mech-recv: rsvp nsis
The answerer supports NSIS in both directions, but not RSVP. Consequently, it returns the following session description:
回答者は、rsvpではなく、両方向でNSIをサポートしています。その結果、次のセッションの説明を返します。
m=audio 55000 RTP/AVP 0
a=qos-mech-send: nsis
a=qos-mech-recv: nsis
This specification registers two new SDP attributes and creates a new registry for QoS mechanisms.
この仕様は、2つの新しいSDP属性を登録し、QoSメカニズムの新しいレジストリを作成します。
IANA has registered the following SDP att-field under the Session Description Protocol (SDP) Parameters registry:
IANAは、セッション説明プロトコル（SDP）パラメーターレジストリの下で、次のSDP att-fieldを登録しています。
Contact name: Gonzalo.Camarillo@ericsson.com
連絡先名：gonzalo.camarillo@ericsson.com
Attribute name: qos-mech-send
属性名：QOS-Mech-Send
Long-form attribute name: QoS Mechanism for the Send Direction
ロングフォーム属性名：送信方向のQoSメカニズム
Type of attribute: Session and Media levels
属性のタイプ：セッションレベルとメディアレベル
Subject to charset: No
charsetの対象：いいえ
Purpose of attribute: To list QoS mechanisms supported in the send direction
属性の目的：送信方向でサポートされているQoSメカニズムをリストするには
Allowed attribute values: IANA Registered Tokens
許可された属性値：IANA登録トークン
IANA has registered the following SDP att-field under the Session Description Protocol (SDP) Parameters registry:
IANAは、セッション説明プロトコル（SDP）パラメーターレジストリの下で、次のSDP att-fieldを登録しています。
Contact name: Gonzalo.Camarillo@ericsson.com
連絡先名：gonzalo.camarillo@ericsson.com
Attribute name: qos-mech-recv
属性名：QOS-Mech-Recv
Long-form attribute name: QoS Mechanism for the Receive Direction
ロングフォーム属性名：受信方向のQoSメカニズム
Type of attribute: Session and Media levels Subject to charset: No
属性のタイプ：Charsetの対象となるセッションとメディアレベル：いいえ
Purpose of attribute: To list QoS mechanisms supported in the receive direction
属性の目的：受信方向でサポートされているQoSメカニズムをリストするには
Allowed attribute values: IANA Registered Tokens
許可された属性値：IANA登録トークン
The IANA has created a subregistry for QoS mechanism token values to be used in the 'qos-mech-send' and 'qos-mech-recv' attributes under the Session Description Protocol (SDP) Parameters registry. The initial values for the subregistry are as follows:
IANAは、セッション説明プロトコル（SDP）パラメーターレジストリの下で「QOS-Mech-Send」および「QoS-Mech-Recv」属性で使用されるQoSメカニズムトークン値のサブレジストリを作成しました。サブレジストリの初期値は次のとおりです。
QoS Mechanism Reference
---------------------------- ---------
rsvp RFC 5432
nsis RFC 5432
As per the terminology in [RFC5226], the registration policy for new QoS mechanism token values shall be 'Specification Required'.
[RFC5226]の用語によると、新しいQoSメカニズムトークン値の登録ポリシーは「必要な仕様」とするものとします。
An attacker may attempt to add, modify, or remove 'qos-mech-send' and 'qos-mech-recv' attributes from a session description. This could result in an application behaving in a non-desirable way. For example, the endpoints under attack may not be able to find a common QoS mechanism to use.
攻撃者は、セッションの説明から「QOS-Mech-Send」および「QOS-Mech-Recv」属性を追加、変更、または削除しようとすることができます。これにより、アプリケーションが非決定不可能な方法で動作する可能性があります。たとえば、攻撃下のエンドポイントは、使用する一般的なQoSメカニズムを見つけることができない場合があります。
Consequently, it is strongly RECOMMENDED that integrity and authenticity protection be applied to SDP session descriptions carrying these attributes. For session descriptions carried in SIP [RFC3261], S/MIME [RFC3851] is the natural choice to provide such end-to-end integrity protection, as described in [RFC3261]. Other applications MAY use a different form of integrity protection.
したがって、これらの属性を運ぶSDPセッションの説明に完全性と信頼性保護を適用することを強くお勧めします。SIP [RFC3261]で掲載されたセッションの説明の場合、[RFC3261]に記載されているように、S/MIME [RFC3851]は、このようなエンドツーエンドの完全性保護を提供する自然な選択です。他のアプリケーションは、異なる形式の整合性保護を使用する場合があります。
Dave Oran helped form this effort. Flemming Andreasen and Magnus Westerlund provided useful comments on this specification.
デイブ・オランはこの努力を形成するのを助けました。Flemming AndreasenとMagnus Westerlundは、この仕様に関する有用なコメントを提供しました。
[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月。
[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell、B.、ed。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年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：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[QoS-NSLP] Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Quality-of-Service Signaling", Work in Progress, February 2008.
[QOS-NSLP] MANER、J.、Karagiannis、G。、およびA. McDonald、「サービス品質のシグナル伝達のためのNSLP」、2008年2月の作業。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[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：SESSION Intioniation Protocol」、RFC 3261、2002年6月。
[RFC3312] Camarillo, G., Ed., Marshall, W., Ed., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312] Camarillo、G.、Ed。、Marshall、W.、ed。、およびJ. Rosenberg、「リソース管理とセッション開始プロトコル（SIP）の統合」、RFC 3312、2002年10月。
Authors' Addresses
著者のアドレス
James Polk Cisco Systems 3913 Treemont Circle Colleyville, Texas 76034 USA
ジェームズ・ポーク・シスコ・システム3913 Treemont Circle Colleyville、Texas 76034 USA
Phone: +1-817-271-3552
EMail: jmpolk@cisco.com
Subha Dhesikan Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
Subha Dhesikan Cisco Systems 170 W. Tasman Drive San Jose、CA 95134 USA
EMail: sdhesika@cisco.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com