Internet Engineering Task Force (IETF) H. Schulzrinne
Request for Comments: 6444 Columbia University
Category: Informational L. Liess
ISSN: 2070-1721 Deutsche Telekom
H. Tschofenig
Nokia Siemens Networks
B. Stark
AT&T
A. Kuett
Skype
January 2012
Internet Engineering Task Force (IETF) H. Schulzrinne
Request for Comments: 6444 Columbia University
Category: Informational L. Liess
ISSN: 2070-1721 Deutsche Telekom
H. Tschofenig
Nokia Siemens Networks
B. Stark
AT&T
A. Kuett
Skype
January 2012
Location Hiding: Problem Statement and Requirements
位置隐藏：问题陈述和需求
Abstract
摘要
The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to endpoints or Voice over IP (VoIP) service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). To determine the PSAP Uniform Resource Identifier (URI), the usage of the Location-to-Service Translation (LoST) protocol is envisioned.
IETF Internet技术紧急上下文解析（ECRIT）工作组开发的紧急服务体系结构描述了一种体系结构，其中位置信息由接入网络提供给端点或IP语音（VoIP）服务提供商，以确定正确的拨号字符串和信息，将呼叫路由到公共安全应答点（PSAP）。为了确定PSAP统一资源标识符（URI），设想使用位置到服务转换（LoST）协议。
This document provides a problem statement and lists requirements for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information.
本文件提供了一份问题陈述，并列出了互联网接入提供商（IAP）和/或互联网服务提供商（ISP）只愿意披露有限或没有位置信息的情况下的要求。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc6444.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6444.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Emergency Services Architecture ............................3
1.2. Location Hiding ............................................3
1.3. Location by Reference ......................................4
2. Terminology .....................................................5
3. Requirements ....................................................5
4. Security Considerations .........................................7
5. Acknowledgments .................................................7
6. Normative References ............................................7
1. Introduction ....................................................3
1.1. Emergency Services Architecture ............................3
1.2. Location Hiding ............................................3
1.3. Location by Reference ......................................4
2. Terminology .....................................................5
3. Requirements ....................................................5
4. Security Considerations .........................................7
5. Acknowledgments .................................................7
6. Normative References ............................................7
The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group, see [RFC6443], describes an architecture where location information is provided by access networks to endpoints or VoIP service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). The Location-to-Service Translation (LoST) protocol [RFC5222] allows callers and other call-routing entities to determine the PSAP Uniform Resource Identifier (URI) for a specific geographical location together with a service URN [RFC5031]. The basic architecture is shown in Figure 1 of [RFC6443] and further detailed in the message flow in Figure 2 of [RFC6443].
IETF互联网技术应急上下文解决（ECRIT）工作组开发的应急服务体系结构，见[RFC6443]，描述一种体系结构，其中接入网络向端点或VoIP服务提供商提供位置信息，以确定将呼叫路由到公共安全应答点（PSAP）的正确拨号字符串和信息。位置到服务转换（丢失）协议[RFC5222]允许呼叫者和其他呼叫路由实体与服务URN[RFC5031]一起确定特定地理位置的PSAP统一资源标识符（URI）。基本架构如[RFC6443]的图1所示，并在[RFC6443]的图2中的消息流中进一步详细说明。
For emergency services, location information is needed for three purposes:
对于紧急服务，位置信息需要用于三个目的：
1. Emergency call routing to the PSAP that is responsible for a specific geographical region.
1. 紧急呼叫路由到负责特定地理区域的PSAP。
2. Dispatch of the emergency personnel to the scene of an accident, crime, or other type of incident.
2. 向事故、犯罪或其他类型事件的现场派遣应急人员。
3. Additionally, a Voice Service Provider (VSP) may need to verify that a call is indeed an emergency call and may therefore require location information to ensure that calls routed to a specific URI point to a PSAP.
3. 此外，语音服务提供商（VSP）可能需要验证呼叫确实是紧急呼叫，因此可能需要位置信息以确保路由到特定URI的呼叫指向PSAP。
This document focuses on items (1) and (3). Providing location information by the ISP to emergency authorities, including PSAPs, regional emergency management association, and emergency personnel is typically a legal obligation covered by regulatory frameworks.
本文件重点介绍第（1）项和第（3）项。ISP向应急机构（包括PSAP、区域应急管理协会和应急人员）提供位置信息通常是监管框架规定的一项法律义务。
Internet Access Providers (IAPs) and Internet Service Providers (ISPs) typically have little incentive to provide location information to end hosts or independent VSPs (without monetary compensation) for any purpose, including for emergency call routing. The decision to deny disclosure of location information can be driven by a number of technical and business concerns. Some providers may perceive a risk that allowing users to access location information for non-emergency purposes or prior to an emergency call will incur additional server load and thus costs. Other providers may not want
互联网接入提供商（IAP）和互联网服务提供商（ISP）通常不会出于任何目的（包括紧急呼叫路由）向终端主机或独立VSP提供位置信息（无金钱补偿）。拒绝披露位置信息的决定可能受到许多技术和业务问题的影响。一些提供商可能会认为，允许用户出于非紧急目的或在紧急呼叫之前访问位置信息会导致额外的服务器负载，从而产生成本。其他提供商可能不需要
to make location information available without the ability to charge for it. Yet, others fear problems with regard to privacy when disclosing location information to potentially unknown third parties.
在不收费的情况下提供位置信息。然而，其他人担心在向潜在的未知第三方披露位置信息时会出现隐私方面的问题。
The work on the Location Configuration Protocol (LCP) indicated the need to provide the capability to obtain Location-by-References (LbyRs) in addition to Location-by-Value (LbyV) from a Location Information Server (LIS).
关于位置配置协议（LCP）的工作表明，除了从位置信息服务器（LIS）获取按值位置（LbyV）外，还需要提供按参考位置（LBYR）获取位置的能力。
The LCP problem statement and requirements document is [RFC5687]. The requirements for obtaining an LbyR via the LCP and the corresponding dereferencing step can be found in [RFC5808].
LCP问题陈述和要求文件为[RFC5687]。通过LCP获得LbyR的要求和相应的解参考步骤见[RFC5808]。
HTTP Enabled Location Delivery (HELD), see [RFC5985], is an instantiation of the LCP concept and allows LbyVs and LbyRs to be requested.
HTTP启用的位置传递（保留），参见[RFC5985]，是LCP概念的一个实例，允许请求LBYV和LBYR。
A location reference may already satisfy the requirement for location hiding if the PSAP has the appropriate credentials to resolve the reference. These credentials allow the ISP/IAP to authenticate and to authorize the party that would like to request location information. The policy to obtain these credentials allows ISPs/IAPs to put constraints under which these credentials are handed out. ISPs/IAPs ideally might want to engage in a business relationship with the VSP to receive a financial compensation for the service they provide. On the Internet, the number of VSPs is potentially large and the VSPs would not want to enter a business contract with potentially every ISP/IAP worldwide. The number of potential contracts between ISPs/IAPs and PSAPs is, however, relatively small as they typically need to have a local relationship as PSAPs provide their emergency services support in a certain geographical region for which certain ISPs/IAPs have networks deployed.
如果PSAP具有解析引用的适当凭据，则位置引用可能已经满足位置隐藏的要求。这些凭据允许ISP/IAP对希望请求位置信息的一方进行身份验证和授权。获取这些凭据的策略允许ISP/IAP对分发这些凭据施加限制。理想情况下，ISP/IAP可能希望与VSP建立业务关系，以便为其提供的服务获得经济补偿。在互联网上，VSP的数量可能很大，VSP不希望与全球潜在的每个ISP/IAP签订业务合同。然而，ISP/IAP和PSAP之间的潜在合同数量相对较少，因为它们通常需要建立本地关系，因为PSAP在某些ISP/IAP部署了网络的特定地理区域提供紧急服务支持。
Note that the requirement being met here is for delivery of location information to the PSAP, not for LoST routing or for validation at the VSP. Since LoST [RFC5222] requires location by value, location by reference cannot be used for location-based routing. Also, LoST servers may be operated by independent parties, including VSPs, which again may not be able to resolve the reference to location by value. (Note that LoST is a protocol used for determining the location-appropriate PSAP based on location information and a Service URN [RFC5031].)
请注意，此处满足的要求是向PSAP交付位置信息，而不是丢失路由或VSP验证。由于LoST[RFC5222]要求按值定位，因此按引用定位不能用于基于位置的路由。此外，丢失的服务器可能由独立方（包括VSP）操作，VSP也可能无法按值解析对位置的引用。（请注意，LoST是一个协议，用于根据位置信息和服务URN[RFC5031]确定适合位置的PSAP。）
The keywords "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], with the important qualification that, unless otherwise stated, these terms apply to the design of an solution supporting location hiding, not its implementation or application.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释，重要的限定条件是，除非另有说明，否则这些术语适用于支持位置隐藏的解决方案的设计，不是它的实现或应用。
This document reuses terminology from [RFC5687].
本文件重复使用[RFC5687]中的术语。
Req-1: There MUST be a way for the ISP/IAP to withhold precise location information from the endpoint and from the VSP.
Req-1：ISP/IAP必须有办法从端点和VSP保留精确的位置信息。
Req-2: The ISP/IAP MUST support the ability of the endpoint or the VSP to route emergency calls.
Req-2:ISP/IAP必须支持端点或VSP路由紧急呼叫的能力。
Req-3: The VSP MUST be able to validate that a call purported to be an emergency call is being routed to a bona fide URI, which is denoted by being a URI in LoST for the designated emergency service. This requirement is provided to deal with potential security problems described in Section 5.1 of [RFC5069].
Req-3：VSP必须能够验证声称是紧急呼叫的呼叫是否被路由到真正的URI，该URI表示为指定紧急服务丢失的URI。本要求用于处理[RFC5069]第5.1节中描述的潜在安全问题。
Req-4: The PSAP MUST receive precise location information (by value) about emergency callers. As such, any solution MUST be able to provide location information to the PSAP even while withholding it from the emergency caller.
Req-4:PSAP必须接收有关紧急呼叫者的精确位置信息（按值）。因此，任何解决方案都必须能够向PSAP提供位置信息，即使对紧急呼叫方不提供位置信息。
Req-5: The proposed solution MUST NOT assume a business or trust relationship between the caller's VSP and the caller's ISP.
Req-5：建议的解决方案不得假设呼叫者的VSP和呼叫者的ISP之间存在业务或信任关系。
Req-6: A solution MUST consider deployment scenarios where a VSP does not operate in the same jurisdiction as the PSAP.
RQ-6：一个解决方案必须考虑部署方案，其中VSP不在与PSAP相同的权限范围内运行。
Req-7: The solution MUST consider that service boundaries for the various emergency services responsible for a particular location may differ.
RQ-7：解决方案必须考虑到负责特定位置的各种急诊科的服务边界可能有所不同。
Req-8: The steps needed by the endpoint for emergency calling SHOULD be no different when location is withheld versus when location is not withheld. In particular, user agents cannot require additional configuration to discover in which particular environment (hiding or no hiding) they find themselves.
Req-8：在保留位置和不保留位置的情况下，端点进行紧急调用所需的步骤应该没有区别。特别是，用户代理不需要额外的配置来发现他们自己在哪个特定环境中（隐藏或不隐藏）。
Req-9: The solution SHOULD work without the ISP/IAP having to support SIP and without the need to utilize SIP between the endpoint and the VSP.
Req-9：该解决方案应该在ISP/IAP不支持SIP的情况下工作，并且不需要在端点和VSP之间使用SIP。
Req-10: The solution MUST work if PSAP boundaries have holes. (For a discussion about holes in PSAP boundaries and their encoding, the reader is referred to [RFC5964].)
Req-10：如果PSAP边界有孔，则解决方案必须有效。（有关PSAP边界中的孔及其编码的讨论，请参阅[RFC5964]。）
Req-11: The solution MUST NOT assume the existence of Emergency Service Routing Proxies (ESRPs) per country, state, and city.
Req-11：解决方案不得假设每个国家、州和城市都存在紧急服务路由代理（ESRP）。
Req-12: The solution MUST consider that service boundaries for different emergency services may differ, but they overlap at the location of the caller.
RQ-12：解决方案必须考虑到不同急诊科的服务边界可能不同，但它们在呼叫者的位置重叠。
Req-13: Though the solution MAY add steps to the emergency call routing process described in [RFC6443], these steps MUST NOT significantly increase call setup latency. For example, the revised process MUST NOT include "trial-and-error" operations on its critical path, such as attempts at LbyR resolutions that may take time to time out.
Req-13：尽管解决方案可能会在[RFC6443]中描述的紧急呼叫路由过程中添加步骤，但这些步骤不得显著增加呼叫设置延迟。例如，修订后的流程不得包括其关键路径上的“试错”操作，例如可能需要时间暂停的LbyR决议尝试。
Req-14: The solution MUST allow the end host to determine PSAP/ESRP URLs prior to the call, for all emergency services.
Req-14：解决方案必须允许终端主机在呼叫之前确定所有紧急服务的PSAP/ESRP URL。
Req-15: The solution MUST allow user agents (UAs) to discover at least their dial string ahead of the emergency call.
Req-15：解决方案必须允许用户代理（UAs）在紧急呼叫之前至少发现其拨号字符串。
Req-16: The solution MUST have minimal impact on UAs, i.e., a solution is preferred if it does not require a substantially different emergency service procedure compared to the procedure of dealing with emergency services where no location hiding is applied.
Req-16：该解决方案必须对UAs的影响最小，即，如果该解决方案不需要与处理无位置隐藏的紧急服务程序有实质性不同的紧急服务程序，则首选该解决方案。
Req-17: The solution MUST NOT interfere with the use of LoST for non-emergency services.
Req-17：该解决方案不得干扰非紧急服务使用LoST。
Req-18: The solution MUST allow emergency calls to reach an IP-to-PSTN gateway rather than the IP-based PSAP directly.
Req-18：解决方案必须允许紧急呼叫到达IP到PSTN网关，而不是直接到达基于IP的PSAP。
Req-19: The solution MUST NOT shift effort (externality), i.e., the convenience of the location-hiding ISP MUST NOT impose a burden on user agents or non-hiding ISPs/IAPs and SHOULD NOT impose a burden on VSPs.
Req-19：解决方案不得转移工作（外部性），即位置隐藏ISP的便利性不得对用户代理或非隐藏ISP/IAP造成负担，也不得对VSP造成负担。
Req-20: The solution SHOULD minimize the impact on LoST, SIP conveyance [RFC6442], and DHCP.
Req-20：解决方案应尽量减少对丢失、SIP传输[RFC6442]和DHCP的影响。
Req-21: The solution SHOULD NOT break in the presence of NATs and SHOULD consider the presence of legacy devices, as described in [RFC5687].
RQ-21：解决方案不应在NAT的存在下中断，并且应考虑遗留设备的存在，如[RCF568]中所描述的。
This document does not raise additional security consideration beyond those mentioned in [RFC5687] and discussed in this document.
除了[RFC5687]中提到的和本文件中讨论的内容外，本文件并未提出额外的安全考虑。
We would like to thank the following ECRIT working group members (in no particular order) for their contributions:
我们要感谢以下ECRIT工作组成员（无特殊顺序）的贡献：
o Andrew Newton (andy@hxr.us)
o 安德鲁·牛顿(andy@hxr.us)
o James Winterbottom (James.Winterbottom@andrew.com)
o 詹姆斯·温特巴顿（詹姆斯·温特巴顿）。Winterbottom@andrew.com)
o Brian Rosen (br@brianrosen.net)
o 布莱恩·罗森(br@brianrosen.net)
o Richard Barnes (rbarnes@bbn.com)
o 理查德·巴恩斯(rbarnes@bbn.com)
o Marc Linsner (mlinsner@cisco.com)
o 马克·林斯纳(mlinsner@cisco.com)
o Ted Hardie (hardie@qualcomm.com)
o 泰德·哈迪(hardie@qualcomm.com)
The authors would also like to thank Ben Campbell for his Gen-ART review. Additionally, we would like to thank Jari Arkko, Alexey Melnikov, Tim Polk, and Dan Romascanu for their IESG review.
作者还要感谢Ben Campbell的Gen ART评论。此外，我们还要感谢贾里·阿尔科、阿列克谢·梅尔尼科夫、蒂姆·波尔克和丹·罗马斯坎努对IESG的评论。
[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月。
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008.
[RFC5031]Schulzrinne，H.，“应急和其他知名服务的统一资源名称（URN）”，RFC 5031，2008年1月。
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008.
[RFC5069]Taylor，T.，Tschofenig，H.，Schulzrinne，H.，和M.Shanmugam，“紧急呼叫标记和映射的安全威胁和要求”，RFC 5069，2008年1月。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[RFC5222]Hardie，T.，Newton，A.，Schulzrinne，H.，和H.Tschofenig，“丢失：位置到服务转换协议”，RFC 5222，2008年8月。
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010.
[RFC5687]Tschofenig，H.和H.Schulzrinne，“GEOPRIV第7层位置配置协议：问题陈述和要求”，RFC 5687，2010年3月。
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010.
[RFC5808]Marshall，R.，“通过参考机制定位的要求”，RFC 5808，2010年5月。
[RFC5964] Winterbottom, J. and M. Thomson, "Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries", RFC 5964, August 2010.
[RFC5964]Winterbottom，J.和M.Thomson，“指定位置孔到服务转换（丢失）服务边界”，RFC 59642010年8月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985]Barnes，M.，“支持HTTP的位置传递（保留）”，RFC 59852010年9月。
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, December 2011.
[RFC6442]Polk，J.，Rosen，B.，和J.Peterson，“会话启动协议的位置传输”，RFC 6442，2011年12月。
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", RFC 6443, December 2011.
[RFC6443]Rosen，B.，Schulzrinne，H.，Polk，J.，和A.Newton，“使用互联网多媒体进行紧急呼叫的框架”，RFC 64432011年12月。
Authors' Addresses
作者地址
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 EMail: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu
Henning Schulzrinne哥伦比亚大学计算机科学系450纽约州纽约市计算机科学大楼10027美国电话：+1 212 939 7004电子邮件：hgs+ecrit@cs.columbia.eduURI:http://www.cs.columbia.edu
Laura Liess Deutsche Telekom Networks Deutsche Telekom Allee 7 Darmstadt, Hessen 64295 Germany Phone: EMail: L.Liess@telekom.de URI: http://www.telekom.de
Laura Liess Deutsche Telekom Networks Deutsche Telekom Allee 7 Darmstadt，Hessen 64295德国电话：电子邮件：L。Liess@telekom.deURI:http://www.telekom.de
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at
Hannes Tschofenig诺基亚西门子网络Linnoitustie 6 Espoo 02600芬兰电话：+358（50）4871445电子邮件：Hannes。Tschofenig@gmx.netURI:http://www.tschofenig.priv.at
Barbara Stark AT&T 725 W Peachtree St, NE Atlanta, GA 30308 USA Phone: +1 404 499 7026 EMail: barbara.stark@att.com
芭芭拉·斯塔克AT&T 725 W Peachtree St，美国佐治亚州亚特兰大东北部30308电话：+1 404 499 7026电子邮件：芭芭拉。stark@att.com
Andres Kuett Skype EMail: andres.kytt@skype.net
Andres Kuett Skype电子邮件：Andres。kytt@skype.net