3.5 File Transfer / 文件传输

3.5.1 Feature description / 功能描述

File Transfer is the ability for users to exchange different types of content (files), during an ongoing session or without having an ongoing session.
文件传输是用户在正在进行的会话期间或在没有正在进行的会话的情况下交换不同类型的内容（文件）的能力。

On the sender’s side, before sending the request to the intended recipient, the file to be transferred and the recipient have to be selected (refer to use cases in section 3.5.6). If the recipient is not registered, and if the recipient has the File Transfer store and forward service capability, it may still be possible to send the file transfer request (refer to use cases in sections 3.5.4.7 and 3.5.4.7.2.1).
在发送方，在将请求发送到预期接收方之前，必须选择要传送的文件和接收方（请参阅第3.5.6节中的用例）。如果收件人未注册，并且收件人具有文件传输存储和转发服务功能，则仍然可以发送文件传输请求（请参阅第3.5.4.7节和第3.5.4.7.2.1节中的用例）。

For pictures or video clips, it is a significant added value if the recipient receives a preview of the proposed file before accepting or declining the transfer. Therefore, whenever possible, the sender of the file should include a thumbnail of the file in the File Transfer invitation. A client receiving a File Transfer request with a thumbnail should display the thumbnail in the pop-up presenting the File Transfer invitation.
对于图片或视频剪辑，如果收件人在接受或拒绝转移之前接收到所提议文件的预览，则这是一个重要的附加值。因此，只要可能，文件的发件人应在文件传输邀请中包含该文件的缩略图。接收具有缩略图的文件传输请求的客户端应在显示文件传输邀请的弹出窗口中显示缩略图。

The request for File Transfer is sent to all of the recipients’ devices. When no automatic acceptance is done, this will trigger a pop-up indicating to the user that a contact wishes to send them the depicted file. The recipient is able to select the device to which the file is transferred by accepting or refusing the File Transfer invitation on that device.
文件传输请求发送到所有收件人的设备。当没有进行自动接受时，这将触发弹出，向用户指示联系人希望向他们发送所描绘的文件。收件人能够通过在该设备上接受或拒绝文件传输邀请来选择文件传输到的设备。

In this pop-up shown prior to the actual transfer of a file, the intended recipient is given the opportunity to learn about the proposed File Transfer (size, name, preview and type of file in addition to the identity of the sender) and then to accept or decline the File Transfer based on this information.
在文件的实际传送之前示出的该弹出窗口中，给予预期接收者机会来了解建议的文件传送（除了发送者的身份之外的文件大小，名称，预览和类型），然后基于此信息接受或拒绝文件传输。

If a File Transfer is interrupted for any reason, the receiver can request resumption of the File Transfer without having to re-start from the beginning.
如果文件传输由于任何原因中断，则接收器可以请求恢复文件传输，而不必从开始重新开始。

Users are allowed to qualify undesired incoming File Transfer requests as spam. To this end, clients may support a locally stored black list to handle incoming File Transfer requests. This is the same black list as it is used for incoming chat requests. If an invitation to receive a file is received from a blacklisted user, the client should reject the File Transfer request, and from the UX, not notify the user. Instead it may log the event in the spam folder (e.g. “User A tried to send a file on TIME/DATE”).
用户可以将不需要的传入文件传输请求限定为垃圾邮件。为此，客户端可以支持本地存储的黑名单以处理传入的文件传输请求。这是与用于传入聊天请求相同的黑名单。如果从黑名单用户接收到接收文件的邀请，则客户机应拒绝文件传输请求，并且不通过UX通知用户。而是可以将事件记录在垃圾邮件文件夹中（例如“用户A试图在TIME/DATE发送文件”）。

The File Transfer feature has the following limitations:
文件传输功能具有以下限制：

Sharing files with a group of users is only considered within a Group Chat Session. Outside of a Group Chat Session, a device UI may initiate multiple 1-to-1 File Transfer sessions to transfer a file to multiple users.
只有在群聊会话中才会考虑与一组用户共享文件。在群聊会话之外，设备UI可以发起多个1对1文件传输会话以将文件传输到多个用户。
Only one file can be sent per file transfer session.
每个文件传输会话只能发送一个文件。

3.5.1.1 Handling of specific content / 处理具体内容

For some of the content exchanged during a file transfer specific handling is provided. This is described in the following subsections
对于在文件传输期间交换的一些内容，提供特定处理。这将在以下小节中描述

3.5.1.1.1 Card Push / 名片推送

Sharing contact information brings different opportunities to RCS, all of them increasing end user contact possibilities e.g. allowing RCS Users to connect with other RCS or non-RCS Users.
共享联系信息为RCS带来了不同的机会，所有这些都增加了最终用户的联系可能性。允许RCS用户与其他RCS或非RCS用户连接。

Currently manufacturers are saving the contact info in their address books without following a fully open standard and, as a consequence, sharing this information effectively with other device manufacturers becomes a challenge.
目前制造商在他们的地址簿中保存联系信息而没有遵循完全开放的标准，因此，与其他设备制造商有效地共享该信息成为挑战。

Also, the concept of ‘personal’ and ‘business’ card, representing the user’s own contact information, which may be stored in the address book, is not used simply because this is not an explicit option of the address book menus of existing devices.
此外，表示可以存储在地址簿中的用户自己的联系人信息的“个人”和“商务”卡的概念不仅仅因为这不是现有设备的地址簿菜单的显式选项而被使用。

This specification aims to:
本规范旨在：

Move towards a standard format compliant with all kinds of devices for keeping contact information.
向符合各种设备的标准格式移动以保持联系信息。
Create and manage personal and business cards and share them with selected contacts and giving this option visibility in the address book menus.
创建和管理个人和名片，并与选定的联系人共享，并在地址簿菜单中提供此选项可见性。
Exchange contact information in a secure way.
以安全的方式交换联系人信息。

RCS brings File Transfer as a new service, which becomes a very good bearer for exchanging of contact cards among users. Those contact cards can be sent to another user, like any other file format, using File Transfer.
RCS使文件传输作为新的服务，这成为用户之间交换联系人卡的非常好的承载。这些联系人卡片可以使用文件传输发送到其他用户，如任何其他文件格式。

3.5.1.1.2 Audio Message / 音频消息

The Audio Messaging feature is described in section 3.11.
第3.11节中描述了音频消息传递功能。

3.5.2 Interaction with other RCS features / 与其他RCS功能的交互

A 1-to-1 File Transfer is not linked to other services (for example, CS-voice call or ongoing chat session) and can be used either during or outside of other communication sessions. The procedure for any file transfer within an ongoing 1-to-1 chat session is implemented as a separate session in parallel with the ongoing 1-to-1 chat and therefore, is the same as the procedure for initiating a separate session for File Transfer.
1对1文件传输未链接到其他服务（例如，CS语音呼叫或正在进行的聊天会话），并且可以在其他通信会话期间或之外使用。在正在进行的1对1聊天会话内的任何文件传输的过程被实现为与正在进行的1对1聊天并行的单独会话，并且因此与用于启动文件传输的单独会话的过程相同。

Different types of content (files) can be exchanged during an ongoing session or without having an ongoing session, i.e. during or outside a call or 1-to-1 chat session.
可以在正在进行的会话期间或者不具有正在进行的会话（即，在呼叫或1对1聊天会话期间或之外）交换不同类型的内容（文件）。

When transferring a file while not in an existing session (that is when not in a call or chat session with the contact with whom the file is to be shared) and after the transfer has started (that is the receiving user accepted the incoming file) the file transfer is presented to the recipient in a chat context. This establishes a communication context for the transfer since the recipient may want to know why the sender is sharing the file. At the time, the file is presented, the chat session is not started. The chat session will only start if and when the receiver sends a chat message back to the sender of the file transfer.
当在不在现有会话（即不在与将与其共享文件的联系人的呼叫或聊天会话中）时传送文件时，并且在传送开始之后（即，接收用户接受传入文件）文件传输在聊天上下文中被呈现给接收者。这建立了用于传送的通信上下文，因为接收者可能想要知道发送者为什么共享该文件。当时，文件被呈现，聊天会话不启动。聊天会话将仅在接收方将聊天消息发送回文件传送的发送方时开始。

Figure 42: Reference UX for file transfer on the receiver side / 图42：用于接收器端文件传输的参考UX

When a file transfer is started during a call with the receiver of the file transfer, the file transfer continues until it is completed or cancelled, i.e. the file transfer will not be terminated when the call ends.
当在与文件传送的接收者的呼叫期间开始文件传送时，文件传送继续，直到其完成或取消，即，当呼叫结束时，文件传送将不会终止。

A File Transfer is possible during a group chat. In this case, the file is sent to all participants that are capable of receiving the file.
在群聊期间可以进行文件传输。在这种情况下，文件将发送到能够接收文件的所有参与者。

3.5.3 High Level Requirements / 高级别要求

3-5-1 Files can be exchanged during a session (e.g. CS voice call or message conversation).
3-5-1 文件可以在会话期间（例如CS语音呼叫或消息会话）进行交换。
3-5-2 A File Transfer can be initiated by either end point while having an ongoing session (e.g. the caller or the callee).
3-5-2 文件传输可以由具有正在进行的会话的任一端点（例如呼叫者或被叫者）发起。
3-5-3 End of file transfer shall not lead to termination of a simultaneous ongoing session.
3-5-3 文件传输结束不得导致同时进行的会话终止。
3-5-4 End of a voice call shall not lead to termination of ongoing file transfer.
3-5-4 语音呼叫的结束不应导致正在进行的文件传输的终止。
3-5-5 Files can be exchanged without having an earlier established session (e.g. directly from a multimedia gallery).
3-5-5 文件可以在没有早先建立的会话的情况下交换（例如直接从多媒体库）。
3-5-6 The receiver must be able to accept or reject offered files. The invitation procedure shall include an indication to the receiving party concerning file size and type.
3-5-6 接收方必须能够接受或拒绝提供的文件。邀请程序应包括对接收方的关于文件大小和类型的指示。
3-5-7 The receiver shall have the possibility to save the transferred files.
3-5-7 接收方应有保存传送文件的可能性。
3-5-8 It shall be possible to assign a service provider configurable maximum file size allowed for File Transfer.
3-5-8 可以为服务提供程序分配文件传输允许的最大文件大小。
3-5-9 The sending and receiving client shall be able to resume an interrupted file transfer. It is up to Service Provider policy whether only the receiving client or either client can initiate the resume request.
3-5-9 发送和接收客户端应能恢复中断的文件传输。由服务提供商策略决定是否只有接收客户端或任一客户端可以发起恢复请求。
3-5-10 The sending client shall have the possibility to include a thumbnail preview of an offered file.
3-5-10 发送客户端应该可以包括提供的文件的缩略图预览。
3-5-11 When sending a file to the recipients in a group chat, the file shall be sent to the network only once.
3-5-11 当在群聊中向收件人发送文件时，文件只能发送到网络一次。
3-5-12 Store & forward: If the intended recipient is not available, or the recipient does not accept the file transfer invitation within a Service Provider define time limit, the file being offered for transfer shall be available for later retrieval, provided the recipient also has the store & forward service and it is enabled (determined by capabilities exchange).
3-5-12 存储和转发：如果预期收件人不可用，或收件人不接受服务提供商定义时间限制内的文件传输邀请，则提供转移的文件应可用于以后检索，前提是收件人还具有存储和转发服务，并且启用（由能力交换确定）。

3.5.4 Technical Realisation / 技术实现

File Transfer is based on [RCS-SIMPLEIM-ENDORS] and [RCS-CPM-CONVFUNC-ENDORS], as well as on the extensions described in [RFC5547]. The technology choice is controlled by the configuration parameter CHAT MESSAGING TECHNOLOGY as described in section A.1.4.3.
文件传输基于[RCS-SIMPLEIM-ENDORS]和[RCS-CPM-CONVFUNC-ENDORS]，以及在[RFC5547]中描述的扩展。技术选择由配置参数CHAT MESSAGING TECHNOLOGY控制，如第A.1.4.3节所述。

A technical variant of File Transfer based on HTTP is also defined in section 3.5.4.8.
基于HTTP的文件传输的技术变体也在3.5.4.8节中定义。

SIP INVITE requests for file transfers will be forked to all the recipient’s devices. If the recipient accepts the invitation on one device, the corresponding client shall respond with a 200 OK response. If the recipient rejects the session, the client shall respond with a 603 response. In both cases, the IMS network of his Service Provider will cancel the invitations to his other devices.
SIP INVITE文件传输请求将分叉到所有收件人的设备。如果接收者在一个设备上接受邀请，则相应的客户端将响应200 OK响应。如果接收者拒绝会话，则客户端应当用603响应来响应。在这两种情况下，他的服务提供商的IMS网络将取消对其他设备的邀请。

The SIP 603 Decline response shall be used for the automatic rejection of the incoming File Transfer invitation in case the initiator is included in the device’s local blacklist that is described in section 3.5.1.
如果启动器包含在3.5.1节中描述的设备的本地黑名单中，则SIP 603拒绝响应应用于自动拒绝传入文件传输邀请。

The current solution provides two complementary technical realisations to provide the file store and forward functionality:
当前的解决方案提供两种补充的技术实现，以提供文件存储和转发功能：

File fetching/re-delivery via SIP and MSRP: In this implementation, the receiver shall either fetch the stored file using the file transfer fetch procedure described in [RFC5547], or send a new invite to the MSRP server that stored it or wait for a new invitation for the file transfer to be sent by the server that has stored the file previously when the user was offline when the transfer was initiated.
通过SIP和MSRP的文件提取/重新传递：在这个实现中，接收器应该使用[RFC5547]中描述的文件传输提取过程提取存储的文件，或者向存储它的MSRP服务器发送一个新的邀请或等待用于当用户在发起传送时离线时先前存储了文件的服务器发送的文件传输的新邀请。
This is described in sections 3.5.4.2 and 3.5.4.7.
这在第3.5.4.2和3.5.4.7节中有描述。
File fetching via HTTPS: In this technical realization, the receiver shall fetch the deferred file using an HTTPS request.
通过HTTPS获取文件：在本技术实现中，接收方应使用HTTPS请求获取延迟文件。
This is described in section 3.5.4.8.
这在3.5.4.8节中有描述。

The two solutions are complementary; therefore, a service provider can choose the best combination to provide the file store and forward service to their customers maximising the resources that are already deployed in their networks.
这两种解决方案是互补的; 因此，服务提供商可以选择最佳组合来向他们的客户提供文件存储和转发服务，从而最大化已经部署在他们的网络中的资源。

The recipient’s client may depending on the setting of client configuration parameter FT AUT ACCEPT (See Table 76 in Section A.1.5) automatically accept the File Transfer invitation from users not included in the device’s local blacklist provided the size indicated in the SDP is below the maximum size for the file transfer warn size (FT WARN SIZE) (See Table 76 in Section A.1.5). Please note in roaming scenarios auto-acceptance shall be disabled by default and if the FT AUT ACCEPT parameter is set, the RCS client shall provide a configuration setting to the user so it can be enabled.
接收方的客户端可以根据客户端配置参数FT AUT ACCEPT（参见A.1.5节中的表76）自动接受来自不包括在设备的本地黑名单中的用户的文件传输邀请，只要SDP中指示的大小低于文件传输警告大小的最大大小（FT WARN SIZE）（参见第A.1.5节中的表76）。请注意，在漫游方案中，默认情况下禁用自动接受，如果设置了FT AUT ACCEPT参数，RCS客户端将向用户提供配置设置，以便可以启用。

If FT AUT ACCEPT (See Table 76 in Section A.1.5) is set to disable automatic acceptance (i.e. set to a value of 0), File Transfer shall be never auto-accepted.
如果FT AUT ACCEPT（参见A.1.5节中的表76）设置为禁用自动接受（即设置为值0），则文件传输永远不会被自动接受。

NOTE: A Service Provider should take into account that enabling any auto- acceptance feature, like the one described above, will impact the multi- device behaviour as it may lead to race conditions.
注意：服务提供商应考虑启用任何自动接受功能（如上所述）会影响多设备行为，因为它可能导致竞争条件。

For File Transfer via MSRP, the extensions described in [RFC5547] are used as follows:
对于通过MSRP的文件传输，[RFC5547]中描述的扩展使用如下：

The SDP payload for File Transfer requests is populated according to [RFC5547], i.e. both sending and receiving clients need to support all elements of [RFC5547]. For populating the file-selector attribute, it is preferable to use the hash-selector, in addition to the other selectors possible. The reason being that the hash-selector uniquely identifies a file, and can also be used to verify the correct transfer of the entire file. The SDP payload shall contain the file size.
文件传输请求的SDP有效载荷根据[RFC5547]填充，即发送和接收客户端都需要支持[RFC5547]的所有元素。为了填充文件选择器属性，除了可能的其它选择器之外，优选地使用哈希选择器。原因是散列选择器唯一地标识文件，并且还可以用于验证整个文件的正确传输。 SDP有效载荷应包含文件大小。
An interrupted file transfer can be resumed by the recipient sending a new SIP INVITE to the originator asking for the missing part of the file. For this it uses the file- range attribute (to denote the missing part) including the file-selector (to denote the file).
中断的文件传输可以通过接收者向发起者发送新的SIP INVITE请求文件的缺失部分来恢复。为此，它使用file-range属性（表示缺少的部分），包括文件选择器（表示文件）。

NOTE: Absence of the file-range attribute denotes transfer of the entire file.
注意：缺少文件范围属性表示传输整个文件。
For such a pull-style operation, the SDP attributes, including file-range and file- selector are populated as described in [RFC5547]. Especially note that from the viewpoint of [RFC5547], this is a new file transfer and hence, it will carry a new file transfer-id attribute.
对于这种拉式操作，如[RFC5547]中所述填充SDP属性，包括文件范围和文件选择器。特别注意，从[RFC5547]的角度来看，这是一个新的文件传输，因此，它将携带一个新的文件transfer-id属性。
If the file recipient is required to resume the File Transfer, the SIP INVITE will be forked to all the registered devices of the originator. In that case, any device which has stored the requested file will answer the SIP INVITE with 200 OK if accepted by the user or the RCS client.
如果文件接收方需要恢复文件传输，则SIP INVITE将被分配给发起方的所有注册设备。在这种情况下，已经存储了所请求的文件的任何设备将在用户或RCS客户端接受时用200 OK来应答SIP INVITE。
For security reasons, an auto-acceptance of resumption requests shall only be offered when a clear correlation between the initial file transfer and the related resumption request can be ensured by the client implementation. In case of manual acceptance, the RCS client application may notify the user that this is a file pull for sake of a resumption request (rather than an ordinary file transfer).
出于安全原因，仅当客户端实现可以确保初始文件传输和相关恢复请求之间的清楚相关时，才应当提供恢复请求的自动接受。在手动接受的情况下，RCS客户端应用可以通知用户这是为了恢复请求（而不是普通文件传输）的文件拉。
Generic file pull scenarios (as described in [RFC5547]), i.e. scenarios that do not pursue on a preceding file transfer as described above, are not supported in this specification.
在本说明书中不支持通用文件拉取场景（如[RFC5547]中所述），即不遵循上述文件传输的场景。
In scenarios where the file sender notices that an initiated file transfer could not complete successfully, such an interrupted file transfer can also be resumed by the file sending client.
在文件发送方注意到启动的文件传输不能成功完成的情况下，这种中断的文件传输也可以由文件发送客户端恢复。
- The procedure for resumption by the file sending client corresponds to the resumption by the file receiving client described above except for the following differences:
  文件发送客户端恢复的过程对应于上述文件接收客户端的恢复，除了以下区别之外：
  - The file sending client will send a new SIP INVITE request with a file selector and a proposed file range in the SDP based on information the file sending client has upon detection of the failure condition.
    文件发送客户端将基于文件发送客户端在检测到故障条件时具有的信息，发送具有文件选择器的新的SIP INVITE请求和SDP中的建议文件范围。
  - The file receiving client will use the file selector and the file range attribute to determine it is a resume request (for this the receiving client may keep information of interrupted file transfers). The file receiving client should include the exact file range required in the SDP returned in the 200 OK on the SIP INVITE request initiating the resumption.
    文件接收客户端将使用文件选择器和文件范围属性来确定它是恢复请求（为此，接收客户端可以保持中断文件传输的信息）。文件接收客户端应该包括在发起恢复的SIP INVITE请求上在200 OK中返回的SDP中所需的确切文件范围。
  - Upon reception of the SDP in the 200 OK, the file sending client shall always use the file range specified by the file receiving client for the resume operation.
    在200 OK中接收到SDP时，文件发送客户端将始终使用由文件接收客户端指定的文件范围用于恢复操作。
- If the file receiving client does not support resumption, the SIP INVITE for the resume will be rejected. The file sending client that initiates the resumption should not continue the resumption. Alternatively, it might then re-send the entire file.
  如果文件接收客户端不支持恢复，则用于恢复的SIP INVITE将被拒绝。启动恢复的文件发送客户端不应继续恢复。或者，它可能重新发送整个文件。
- If both clients initiate resume, the file recipient’s request should be given preference since the file recipient has accurate information about the missing parts of the file. This means that in that case the file recipient client will decline the SIP INVITE request issued by the file sending client.
  如果两个客户端都启动恢复，则文件接收方的请求应该被优先选择，因为文件接收方具有关于文件的丢失部分的准确信息。这意味着在这种情况下，文件接收方客户端将拒绝由文件发送方客户端发出的SIP INVITE请求。
If the contact has indicated the capability for receiving a thumbnail through either the inclusion of the urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.ftthumb in a SIP OPTIONS based exchange or the org.openmobilealliance:File-Transfer-thumb service description in case of a Presence based capability exchange, a preview of an offered file can be added to the SDP description of the SIP INVITE request by using the file-icon attribute of [RFC5547]. The size of this thumbnail shall be smaller than 10 kB. Other SDP attributes will be populated as described in [RFC5547].
如果联系人已经在基于SIP OPTIONS的交换中包括了urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.ftthumb，或者在基于存在性的能力交换中包括了org.openmobilealliance:File-Transfer-thumb服务描述符，通过这些情况声明了接收缩略图的能力，可以通过使用[RFC5547]的文件图标属性来将提供的文件的预览添加到SIP INVITE请求的SDP描述。此缩略图的大小应小于10 kB。将按照[RFC5547]中所述填充其他SDP属性。
- The procedure describing how to create the thumbnail itself, in its raw binary form, is out of scope of this specification. For a picture, the raw binary result shall be a thumbnail of the picture itself. For a video clip, the raw binary result shall be a thumbnail either of the first I-Frame at 20% of the total length of the video clip or of another relevant frame.
  描述如何以其原始二进制形式创建缩略图本身的过程超出了本规范的范围。对于图片，原始二进制结果将是图片本身的缩略图。对于视频剪辑，原始二进制结果将是在视频剪辑或另一相关帧的总长度的20％处的第一个I-fRAME的缩略图。
- The size of a thumbnail should be restricted to the minimum number of octets that provide significance.
  缩略图的大小应限制为提供重要性的最小字节数。

NOTE: It is no longer possible to disable the thumbnail capability. As described in section 2.6.1, a client implementing this version of RCS shall always indicate the capability when File Transfer via MSRP is enabled.
注意：不能再禁用缩略图功能。如第2.6.1节所述，实现此版本RCS的客户端应始终指示启用通过MSRP的文件传输时的能力。

In the following sections, the relevant message flows and reference UX are shown. These are based upon the following assumptions:
在以下部分中，将显示相关的消息流和参考UX。这些基于以下假设：

For simplicity, the internal mobile network interactions are omitted in the diagrams that are shown.
为了简单起见，在所示的图中省略了内部移动网络交互。
It is assumed that by the time the file transfer begins, both the sender and the recipient have exchanged their capabilities using an OPTIONS or Presence exchange. Note that if there is a UX flow that does not show this, the assumption is that the OPTIONS or Presence requests were exchanged between the sender and the receiver (bidirectional) prior to starting the flow.
假设在文件传输开始时，发送者和接收者都使用OPTIONS或Presence交换来交换他们的能力。请注意，如果有一个UX流没有显示这一点，则假设OPTIONS或Presence请求在启动流之前在发送方和接收方（双向）之间交换。

For File Transfer via MSRP, the RCS client shall populate the P-Preferred-Service header field in all CPM or SIMPLE IM requests with the CPM Feature tag defined for the service, as described in [RCS-CPM-CONVFUNC-ENDORS]. The S-CSCF or AS that performs the service assertion in the originating network shall add the P-Asserted-Service header field set to the value of the asserted CPM service ICSI (i.e. urn:urn-7:3gpp- service.ims.icsi.oma.cpm.filetransfer for CPM File Transfer, urn:urn-7:3gpp- service.ims.icsi.oma.cpm.filetransfer.group for CPM File Transfer to a group or urn:urn- 7:3gpp-service.ims.icsi.oma.cpm.deferred for deferred delivery done as part of the store and forward realization) and remove the P-Preferred-Service header field before further routing the request.
对于通过MSRP的文件传输，RCS客户端将使用为该服务定义的CPM特征标记填充所有CPM或SIMPLE IM请求中的P-Preferred-Service报头字段，如[RCS-CPM-CONVFUNC-ENDORS]中所述。在始发网络中执行服务断言的S-CSCF或AS将添加设置为断言的CPM服务ICSI的值的P断言服务报头字段（即，urn:urn-7:3gpp-service.ims.icsi .oma.cpm.filetransfer用于CPM文件传输，urn:urn-7:3gpp-service.ims.icsi.oma.cpm.filetransfer.group用于将CPM文件传输到组或urn:7:3gpp-service.ims.icsi.oma.cpm.deferred用于作为存储和转发实现的一部分进行的延迟传递），并在进一步路由请求之前删除P-Preferred-Service头字段。

NOTE: During a transition period towards full compliance, the network support for asserting the service is recommended but not mandatory.
注意：在完全合规的过渡期间，建议对强制服务的网络支持，但不是强制性的。

A receiving network element and RCS client should ignore any SIP header fields that they do not understand (e.g. P-Preferred-Service or P-Asserted-Service header fields).
接收网络元件和RCS客户端应该忽略他们不理解的任何SIP报头字段（例如，P-Preferred-Service或P-Asserted-Service报头字段）。

3.5.4.1 File Transfer outside Group Chat / 群聊外的文件传输

3.5.4.1.1 Selecting the file transfer recipient(s) / 选择文件传输接收者

The user willing to share a file from the media gallery or file browser will select the file and choose the user with whom the file will be shared. The list that is presented initially to the user may contain RCS contacts not currently registered and to which no store and forward is available. In addition, the capabilities the client has for a contact may not have been updated.
愿意从媒体库或文件浏览器共享文件的用户将选择文件并选择文件将与之共享的用户。最初呈现给用户的列表可以包含当前未注册的并且没有存储和转发可用的RCS联系人。此外，客户端对联系人的功能可能尚未更新。

Therefore, the first step is to determine whether the file can be shared with the selected user (that is that user should be registered or be able to receive files using store and forward and the right capabilities should be in place).
因此，第一步是确定文件是否可以与所选择的用户共享（即，用户应该被注册或能够使用存储和转发来接收文件，并且正确的能力应该就位）。

Figure 43: Selecting users when sharing a file from the media gallery/file browser / 图43：从媒体库/文件浏览器共享文件时选择用户

Independently of the file share UX entry point, once the file and recipient are selected, the transfer can begin. If a user chooses to share several files, the individual file transfers (in each transfer only a single file is shared) are serialised by waiting for a SIP BYE before issuing the SIP INVITE request for the next file to transfer.
独立于文件共享UX入口点，一旦选择了文件和收件人，就可以开始传送。如果用户选择共享几个文件，则在发出SIP INVITE请求以下一个要传输的文件之前，通过等待SIP BYE来序列化单个文件传输（在每次传输中仅共享单个文件）。

In the following diagram, it is assumed the receiver accepts the transfer.
在下图中，假设接收器接受传输。

Figure 44: Standard file transfer sequence diagram – Successful transfer / 图44：标准文件传输序列图 - 成功传输

As shown in Figure 44, a client shall send the file in different MSRP chunks without waiting on the MSRP 200 OK response before transmitting the next chunk.
如图44所示，客户端将在发送下一个块之前不等待MSRP 200 OK响应，而在不同的MSRP块中发送文件。

As also shown in Figure 44, for a successful file transfer the client shall only send a SIP BYE after an MSRP 200 OK response has been received to all chunks of the file.
还如图44所示，对于成功的文件传输，客户端将仅在已经接收到文件的所有块的MSRP 200 OK响应之后才发送SIP BYE。

In the following diagram, User B rejects the transfer.
在下图中，用户B拒绝传输。

Figure 45: Standard file transfer sequence diagram – Receiver rejects the transfer / 图45：标准文件传输序列图 - 接收方拒绝传输

3.5.4.2 File Transfer via MSRP in Group Chat / 在群聊中通过MSRP进行文件传输

For File Transfer in Group Chat the file shall be sent to the conference focus. To support this the conference focus shall indicate in the Contact header field during the setup of the Group Chat whether File Transfer can be used in the Group Chat by including the IARI tags for the RCS File Transfer services it supports (see Table 7 and Table 11):
对于在群聊中的文件传输，文件应发送到会议焦点。为了支持这一点，会议焦点应该在群聊的设置期间在联系人头字段中指示文件传送是否可以在群聊中使用，包括它支持的RCS文件传送服务的IARI标签（见表7和表11 ）：

The File Transfer Service itself (including the support for the Thumbnail)
文件传输服务本身（包括对缩略图的支持）
File Transfer Store and Forward
文件传输存储和转发
Geolocation PUSH (see section 3.10)
地理位置PUSH（见第3.10节）

NOTE1: These shall be included next to the ICSI for CPM Session Mode messaging or the +g.oma.sip-im feature tag if the chat is based on SIMPLE IM.
注1：如果聊天基于SIMPLE IM，这些标记应包含在CPM会话模式消息的ICSI旁边或+g.oma.sip-im功能标记中。

Similarly, a client initiating, invited to or joining a Group Chat shall include those same tags in the Contact header it includes in respectively the SIP INVITE and 200 OK response for that Group Chat. To indicate its support for this mechanism, a client which is not capable of File Transfer at all shall include the tag for Chat defined in Table 7. Clients supporting File Transfer may include this attribute as well.
类似地，发起，邀请或加入群聊的客户端将包括在分别包括用于该群聊的SIP INVITE和200 OK响应的联系人头部中的那些相同标签。为了表明其对这种机制的支持，不能进行文件传输的客户端将包括表7中定义的Chat的标签。支持文件传输的客户端也可以包括该属性。

Also, a Messaging Server accepting the Group Chat session on behalf of the user in Group Chat store and forward scenarios shall provide its capabilities in the Contact header allowing it to indicate for example whether for that user File Transfer is possible depending on store and forward for File Transfer being supported. When the Messaging Server takes the Group Chat session over from the user (e.g. when the user loses connectivity) or the user takes over from the Messaging Server (e.g. after regaining connectivity), the newly applicable set of capabilities shall be announced to the conference focus using a session refresh (i.e. a re-INVITE with an updated Contact header) sent by the Participating Function.
此外，代表用户在群聊存储和转发场景中接受群聊会话的消息服务器应当在联系人头部中提供其能力，使得它能够指示例如对于该用户，文件传输是否可能取决于存储和转发支持文件传输。当消息服务器从用户取得群聊会话（例如，当用户失去连接性时）或用户从消息服务器接管（例如，在恢复连接之后）时，新适用的能力集合将被通告给会议焦点，使用由参与功能发送的会话刷新（即，具有更新的联系报头的重新邀请）。

When the conference focus indicated support for File Transfer, a client that wants to initiate a File Transfer shall compose a multiparty File Transfer Invitation as described in section 10.1 of [RCS-SIMPLEIM-ENDORS] or section 7.4.1 of [RCS-CPM-CONVFUNC-ENDORS] with following differences:
当会议焦点指示对文件传输的支持时，想要启动文件传输的客户端应当按照[RCS-SIMPLEIM-ENDORS]的第10.1节或[RCS-CPM-ENDORS]的第7.4.1节描述的那样组成多方文件传输邀请具有以下差异：

The invitation shall be targeted at the IM Session Identity associated to the chat and thus to the conference focus instead of to the conference factory.
邀请将针对与聊天相关联的IM会话标识，并且因此针对会议焦点而不是会议工厂。
The invitation shall take into account the capabilities of the focus. To avoid backward compatibility problems, the client shall for example not include a thumbnail if not supported by the conference focus.
邀请应考虑焦点的能力。为了避免向后兼容性问题，如果会议焦点不支持，客户端应该例如不包括缩略图。
No recipient-list shall be included.
不包括收件人名单。

NOTE2: When File Transfer is not supported by the focus, a client can still send a file by initiating individual 1-to-1 File Transfer sessions to the chat participants.
注意：当焦点不支持文件传输时，客户端仍然可以通过向聊天参与者发起单个1对1文件传输会话来发送文件。

The participating functions and IMS will route the request to the focus that will generate individual INVITE requests for the participants as described in section 10.4 of [RCS- SIMPLEIM-ENDORS] or section 9.3 of [RCS-CPM-CONVFUNC-ENDORS] with following differences:
参与功能和IMS将将请求路由到焦点，将如在[RCS-SIMPLEIM-ENDORS]的第10.4节或[RCS-CPM-CONVFUNC-ENDORS]的第9.3节中描述的产生针对参与者的单独的INVITE请求，具有以下差异：

The conference focus shall generate INVITE requests for all clients that indicated support for File Transfer in the Contact Header during the setup of the Group Chat. In the generated INVITE requests, the conference focus will take into account the capabilities of the contact as indicated in that Contact Header and for example remove a thumbnail if one was included and no support for the thumbnail was indicated by the recipient
会议焦点应在建立群聊期间对所有指示支持联系人标题中的文件传输的客户端生成INVITE请求。在所生成的INVITE请求中，会议焦点将考虑该联系人报头中指示的联系人的能力，并且例如在包括缩略图的情况下移除缩略图，并且由接收者指示不对缩略图的支持
The conference focus shall not generate INVITE requests to any recipients that has indicated not to support File Transfer in Group Chat (i.e. only the IARI for Chat was included in the Contact header for that participant).
会议焦点不应该向指示不支持在群聊中的文件传送的任何接收者产生INVITE请求（即，只有用于聊天的IARI被包括在该参与者的联系人报头中）。

NOTE3: The conference focus may, based on local server policy, inform the participants in the chat that have indicated not to support File Transfer through a system message of the fact that a file transfer took place that they could not support.
注3：会议焦点可以基于本地服务器策略，通过系统消息通知聊天中已经指示不支持文件传输的参与者发生文件传输，他们不能支持。
The conference focus shall handle participants that have not indicated capabilities in the Contact header during the setup of the Group Chat using one of the following options based on local server policy:
会议焦点将根据本地服务器策略，在设置群聊期间使用以下选项之一来处理在联系人头中未指示功能的参与者：
- Not generate any INVITE requests for File Transfer for that participant (i.e. handle them in the same way as participants that have indicated not to support File Transfer in the Chat).
  不为该参与者产生文件传输的任何INVITE请求（即以与在聊天中不支持文件传输的参与者相同的方式处理它们）。
- Generate a 1-to-1 INVITE request for a File Transfer on behalf of the initiator of the File Transfer without including a Thumbnail or supporting File Transfer store and Forward. If the recipient does not support File Transfer this may fail.
  为文件传输的发起者代表文件传输生成1对1 INVITE请求，而不包括缩略图或支持文件传输存储和转发。如果收件人不支持文件传输，则可能会失败。
For those participants that have announced their capabilities through the Contact header, the conference focus may target the INVITE request at only the device of the participant that is handling the chat session through the mechanisms detailed in section 2.11.2.
对于通过联系人头部宣布其能力的那些参与者，会议焦点可以通过第2.11.2节中详细描述的机制，仅在正在处理聊天会话的参与者的设备处将INVITE请求作为目标。
The conference focus shall not include a recipient-list-history body in the generated INVITE requests.
会议焦点不应在所生成的INVITE请求中包括收件人列表历史记录主体。
The conference focus may, based on local server policy, limit the number of ongoing file transfers to a participant.
会议焦点可以基于本地服务器策略来限制正在进行的向参与者的文件传输的数量。

A client can detect that a File Transfer request coming from the conference focus is associated with a Group Chat in which it is involved this because the File Transfer Contact Header matches the one from the associated Group Chat.
客户端可以检测到来自会议焦点的文件传送请求与其涉及的群聊相关联，因为文件传送联系人报头匹配来自相关联的群聊的报文。

If the Group Chat has been closed due to inactivity when the user wants to send the file to the chat, the Group Chat will be reactivated as stated in section 3.4.4.1.7 before sending the file. After the delay to allow this reestablishment as described in the same section, the File Transfer will be initiated to the Group Chat’s focus.
如果在用户希望将文件发送到聊天时由于闲置而关闭了群聊，则在发送文件之前，将按照第3.4.4.1.7节所述重新激活群聊。在允许此重新建立的延迟之后，如同一部分中所描述的，文件传输将被发起到群聊的焦点。

As in the case of store and forward (See sections 3.5.4.7 and 3.5.4.8) client shall use a CPIM wrapper to request delivery reports if the user wants to be informed about the delivery of the file to the different participants. This wrapper shall be handled by the conference focus for those recipients that do not support store and forward (as indicated in the Contact header provided during the setup of the Group Chat session). The conference focus shall send the content to such a participant without CPIM wrapper and when the file is delivered to that participant the focus may send the corresponding delivery report to the sender either through a SIP MESSAGE (similar to the case where it is generated by the participating function or through an MSRP SEND request in the Chat session.
如存储和转发（参见第3.5.4.7节和3.5.4.8节），如果用户想要通知有关向不同参与者传送文件的情况，则客户端应使用CPIM包装器来请求传送报告。此包装应由会议焦点处理，用于不支持存储和转发的收件人（如在设置群聊会话期间提供的联系人标题中所指示的）。会议焦点应当将内容发送给没有CPIM包装器的这样的参与者，并且当文件被递送给该参与者时，焦点可以通过SIP MESSAGE将相应的递送报告发送到发送者（类似于由或通过聊天会话中的MSRP SEND请求。

NOTE: Contrary to the Group Chat itself, for a File Transfer the conference focus has to provide all packets sent in the session to a participant that is late to accept rather than just those that are sent from the moment the recipient joins.
注意：与群聊本身相反，对于文件传输，会议焦点必须将会话中发送的所有数据包提供给迟到接受的参与者，而不仅仅是从接收者加入时发送的那些数据包。

If the initiator of the File Transfer loses connectivity during the transfer, the initiator may attempt a resume of the File Transfer after re-joining the Group Chat. If connectivity is lost by a recipient that recipient may attempt a resume after re-joining the Group Chat (as described for File Transfer Store and Forward in section 3.5.4.7). That resume request will not be relayed by the Group Chat focus to the initiator of the corresponding File Transfer though. Instead the focus shall send a SIP 488 Not Acceptable Here Error Response.
如果文件传输的启动器在传输期间失去连接，则启动器可能会在重新加入群聊后尝试恢复文件传输。如果收件人在重新加入群聊后尝试恢复连接（如第3.5.4.7节中关于文件传输存储和转发所述），则连接丢失。该恢复请求不会由群聊焦点中继到相应文件传输的发起者。相反，焦点应发送一个SIP 488不可接受的错误响应。

If the Group Chat is terminated while a File Transfer is ongoing, the Group Chat conference focus may, based on local server policy, interrupt the ongoing File Transfer. Whether this is done can depend on the reason the Group Chat session was terminated.
如果在文件传输正在进行时终止群聊，则基于本地服务器策略，群聊会议焦点可以中断正在进行的文件传输。是否完成此操作可以取决于群聊会话终止的原因。

All this leads to the following flow:
所有这一切导致以下流程：

Figure 46: File Transfer in Group Chat / 图46：群聊中的文件传输

There are several scenarios in which a file transfer can result in an error:
在某些情况下，文件传输可能会导致错误：

Either the sender or the receiver decides to cancel the operation before the transfer is completed. The relevant sequences are equivalent to the diagrams presented for image sharing during a voice call in sections 3.6.4.7.8 and 3.6.4.7.9.
发送方或接收方决定在传输完成之前取消操作。相关序列等效于在语音呼叫期间用于图像共享的图表，在3.6.4.7.8节和3.6.4.7.9节中。

NOTE1: Because in RCS only a single file is transferred in a file transfer session, this simplified procedure for the receiver shall be used instead of the one defined in [RFC5547] (referred to from [RCS-SIMPLEIM-ENDORS] and [RCS-CPM-CONVFUNC-ENDORS]).
注1：因为在RCS中，在文件传输会话中只传输单个文件，所以应使用接收器的简化过程，而不是[RFC5547]中定义的过程（从[RCS-SIMPLEIM-ENDORS]和[RCS- CPM-CONVFUNC-ENDORS]）。

Either the sender or the receiver loses the connection to the network before the transfer is completed. The relevant sequences are equivalent to those presented for image sharing during a voice call in sections 3.6.4.7.12 and 3.6.4.7.13.
发送方或接收方在传输完成之前失去与网络的连接。相关序列等效于在语音呼叫期间用于图像共享的部分，在3.6.4.7.12和3.6.4.7.13节中。

When transferring larger files, the probability is higher that such a transfer would be interrupted. If such an interrupt leads to termination of the underlying MSRP session, the receiving client, knowing the overall size of the file in transfer, will become a requester of a file (as described in [RFC5547]) and sends a SIP INVITE request, specifying in the SDP payload this file (by using the file-selector as described in [RFC5547]) and the missing part of the file, using the file-range attribute.
当传送较大文件时，这种传送将被中断的概率较高。如果这样的中断导致底层MSRP会话的终止，则知道传送中的文件的整体大小的接收客户端将变成文件的请求者（如[RFC5547]中所描述的），并且发送SIP INVITE请求，指定此文件的SDP有效负载（通过使用[RFC5547]中描述的文件选择器）和文件的缺失部分，使用file-range属性。

Finally, note that if during a file transfer the capabilities of one of the ends change, the file transfer may be affected:
最后，请注意，如果在文件传输期间其中一个端点的功能发生更改，则文件传输可能会受到影响：

If the receiver runs out of storage space, the sequence should be equivalent to that presented in section 3.6.4.7.10.
如果接收器用完存储空间，则序列应等同于第3.6.4.7.10节中所述。
If on one of the ends a handover into 2G (2G GPRS data coverage) occurs without losing the IP configuration, the file transfer should continue until finished.
如果在其中一端发生切换到2G（2G GPRS数据覆盖）而不丢失IP配置，文件传输应该继续，直到完成。

If the PNB feature is supported[31], the BPEF checks the recipient of a file transfer against the originating PNB ‘rcs_pnb_outft_blockedusers’ of the sender. If the recipient is found on the list, the BPEF will reject the setup of the SIP INVITE session with the blocked user.
如果支持PNB特性[31]，BPEF检查文件传输的接收者与发送者的始发PNB 'rcs_pnb_outft_blockedusers'。如果在列表上找到收件人，则BPEF将拒绝与阻止的用户的SIP INVITE会话的建立。

NOTE2: For File Transfer, the BPEF may be located in the Messaging Server.
注2：对于文件传输，BPEF可能位于消息传递服务器中。

[31] The present section assumes the BPEF as described in section 2.15.1 is provided by the Messaging Server.
[31] 本节假定消息服务器提供了第2.15.1节中描述的BPEF。

In principle the RCS file transfer service comes without a limitation on the file sizes or types. This means that any kind of file can be transferred using this service. Taking this into account and with the aim of providing all the necessary facts to the receiver allowing making an informed decision on whether to accept or to reject the file, a user receiving a file transfer invitation should be informed at a minimum of:
原则上，RCS文件传输服务没有对文件大小或类型的限制。这意味着可以使用此服务传输任何类型的文件。考虑到这一点，并且为了向接收方提供所有必要的事实，允许对是否接受或拒绝文件作出明智的决定的目的，接收文件传送邀请的用户应当至少通知：

The size of the file: This is mainly to protect the user from unexpected charges and/or long transfers.
文件大小：这主要是为了保护用户免受意外收费和/或长期传输。

NOTE: This also applies to the sender.
注意：这也适用于发件人。
The file type: In this case and to make it more intuitive, the device should present to the user whether the file which is being transferred can be handled/displayed by the device.
文件类型：在这种情况下，为了使其更直观，设备应向用户呈现正在传输的文件是否可由设备处理/显示。

For example, if a user receives an invitation to receive a PDF (Portable Document Format) document and their device cannot process that document, an informative message with the size and the fact that the file type is not supported should be presented to the user prior to the user making the decision on accepting or rejecting the file transfer.
例如，如果用户接收到接收PDF（可移植文档格式）文档的邀请并且他们的设备不能处理该文档，则应当在用户做出接受或拒绝文件传输的决定之前，向用户呈现具有大小和不支持文件类型的事实的信息性消息。

Finally note that each individual Service Provider may introduce restrictions taking into account different considerations such as security, intellectual property and so on.
最后请注意，每个单独的服务提供商可能会考虑到不同的考虑因素，如安全性，知识产权等等，引入限制。

3.5.4.5 Personal Network Blacklists handling / 个人网络黑名单处理

NOTE: In the present section, the BPEF as described in section 2.15.1 may be provided by the Messaging Server.
注意：在本节中，第2.15.1节中描述的BPEF可以由消息传递服务器提供。

The Personal Blacklists are applied by the BPEF at both origination and termination of file transfer.
个人黑名单由BPEF在文件传输的发起和终止时应用。

The following resource-lists from Shared XDMS are checked by the BPEF by comparing the URI values used in the request and in the list:
来自Shared XDMS的以下资源列表由BPEF通过比较请求中和列表中使用的URI值进行检查：

At origination:
起始时：
- a) The BPEF of the originator checks the ‘rcs_pnb_outft_blockedusers’ list to verify that the recipient is not among the blocked users for this request by comparing URIs contained in the list with the URI value of the Request URI of the SIP request.
  a) 发起方的BPEF通过将列表中包含的URI与SIP请求的请求URI的URI值进行比较，检查“rcs_pnb_outft_blockedusers”列表，以验证收件人不在此请求的阻止用户之中。
- b) If this is the case, the message is discarded and a SIP a 403 Forbidden response with a warning header set to “122 Function not allowed” is returned to the user.
  b) 如果是这种情况，则丢弃该消息，并且向用户返回具有设置为“122 Function not allowed”的警告标题的SIP a 403禁止响应。
At termination:
终止时：
- a) The BPEF checks the ‘rcs_pnb_ft_blockedusers’ list, to verify if the originator of the file transfer is among the blacklisted users by comparing the URIs contained in the list with the URI values of the P-Asserted-Identity header field of the SIP request.
  a) BPEF检查'rcs_pnb_ft_blockedusers'列表，以通过将列表中包含的URI与SIP请求的P-Asserted-Identity头字段的URI值进行比较来验证文件传输的发起者是否在黑名单用户之中。
- b) If true, the BPEF returns a 403 Forbidden with a warning header set to “122 Function not allowed”
  b) 如果为true，则BPEF返回403 Forbidden，警告标头设置为“122 Function not allowed”
- c) If the Common Message Store is supported it shall store the File Transfer History object data as defined in [RCS-CPM-MSGSTOR-ENDORS] for the blocked File Transfer event in user’s dedicated Blocked Folder.
  c) 如果支持公共消息存储，它将按照[RCS-CPM-MSGSTOR-ENDORS]中的规定存储文件传输历史对象数据，用于用户专用的阻止文件夹中的阻止文件传输事件。

3.5.4.6 File size considerations / 文件大小注意事项

To prevent both the abuse of the file transfer functionality and protect customers from unexpected charges, a configurable size limitation (refer to FT WARN SIZE, FT MAX SIZE and FT MAX SIZE INCOMING in Table 76 for reference) may be enabled.
为了防止滥用文件传输功能和保护客户免受意外收费，可以启用可配置的大小限制（请参见表76中的FT WARN SIZE，FT MAX SIZE和FT MAX SIZE INCOMING）。

From the user experience perspective and assuming that the size limitation is in place (i.e. the values are non-zero):
从用户体验的角度来看，并假定大小限制已到位（即值非零）：

If a file transfer (send or receive) involves a file bigger than FT WARN SIZE, the terminal should warn the user of the potential associated charges and get confirmation from the user to proceed.
如果文件传输（发送或接收）涉及大于FT WARN SIZE的文件，则终端应警告用户潜在的相关费用并获得用户的确认以继续。
If a file to be sent is bigger than FT MAX SIZE, a warning message is displayed when trying to send and at protocol level following action is taken:
如果要发送的文件大于FT MAX SIZE，则尝试发送时将显示警告消息，并且在协议级别采取以下操作：
- For mobile originated file transfer over MSRP the client shall not send the SIP INVITE request.
  对于通过MSRP的移动发起的文件传输，客户端不应发送SIP INVITE请求。
- For mobile originated file transfer over HTTP the client shall not upload the file to the HTTP content server.
  对于通过HTTP的移动发起的文件传输，客户端不应将文件上传到HTTP内容服务器。
If a file is bigger than FT MAX SIZE (when FT MAX SIZE INCOMING is not provisioned) or FT MAX SIZE INCOMING (if it is provisioned) is being received, a warning message is displayed and at protocol level following action is taken:
如果文件大于FT MAX SIZE（未设置FT MAX SIZE INCOMING）或FT MAX SIZE INCOMING（如果已设置），则会显示一条警告消息，并在协议级别采取以下操作：
- For mobile terminated file transfer over MSRP the client shall send an automatic rejection response SIP 403 Forbidden with a Warning header set to “133 Size exceeded”.
  对于通过MSRP的移动终止文件传输，客户端应发送自动拒绝响应SIP 403禁止，警告标题设置为“133 Size exceeded”。
- For mobile terminated messages the chat message with the file transfer over HTTP file-info element with a file size indication exceeding the limit shall be accepted by the client. The file shall not be downloaded from the HTTP content server. Consequently no display notification will be sent to the other end.
  对于移动终止的消息，具有超过限制的文件大小指示的通过HTTP文件信息元素的文件传输的聊天消息将被客户端接受。不应从HTTP内容服务器下载文件。因此，没有显示通知将被发送到另一端。

3.5.4.7 File transfer store and forward using a MSRP-based File Transfer Function (FTF) / 使用基于MSRP的文件传输功能（FTF）的文件传输存储和转发

This functionality requires a logic server function identified as the File Transfer Function (FTF).
此功能需要标识为文件传输功能（FTF）的逻辑服务器功能。

NOTE: As a logical function this can be either provided as part of a physical application server that it is already providing analogous functionality (e.g. Messaging AS) or in a separate one.
注意：作为逻辑功能，它可以作为已经提供类似功能（例如消息传递AS）的物理应用服务器的一部分提供，或者作为单独的功能提供。

The client shall assume that the functionality is available when the recipient has indicated the corresponding capability (see section 2.6.1) and the CHAT MESSAGING TECHNOLOGY configuration parameter described in section A.1.4.3 is set to OMA CPM.
当接收方已经指示了相应的能力（见第2.6.1节）并且第A.1.4.3节中描述的CHAT MESSAGING TECHNOLOGY配置参数设置为OMA CPM时，客户端应假设该功能可用。

This procedure allows the file store and forward mechanism for the following use cases:
此过程允许文件存储和转发机制用于以下用例：

When the receiver ignores the file transfer invitation causing the SIP INVITE procedure to expire or an early expiration due to an error.
当接收方忽略导致SIP INVITE过程的文件传输邀请或由于错误导致的提前到期时。
When the receiving user is offline.
当接收用户离线时。
When the either sender or receiver loses connectivity.
当发送方或接收方失去连接时。

This is reflected in Table 32 that shows the error responses that will result in the FTF storing the file:
这反映在表32中，该表显示了将导致FTF存储文件的错误响应：

Response received on terminating leg	Response sent on originating leg	Store the file
480 Temporarily unavailable	200 OK	Y
408 Request Timeout	200 OK	Y
487 Request Terminated	200 OK	Y
500 Server Internal Error	200 OK	Y
503 Service Unavailable	200 OK	Y
504 Server Timeout	200 OK	Y
600 Busy Everywhere	200 OK	Y
Any other response (including 404 Not Found, 603 Decline, 403 Forbidden and 200 OK)	Received response (that is no mapping is done)	N

Table 32: Mapping of received Error Responses by the FTF / 表32：FTF接收到的错误响应的映射

3.5.4.7.1 File transfer invitation / 文件传输邀请

If supported by a service provider, this functionality shall be provided by the terminating side (receiver) and, optionally, it can be also provided by the originating side, as per the steps provided below:
如果服务提供商支持，则该功能应由终止侧（接收者）提供，并且可选地，还可以由始发侧根据以下提供的步骤提供：

After the capability exchange takes place, the sending client shall verify that both the sender and the receiver support the file transfer store and forward feature.
在能力交换发生后，发送客户端将验证发送方和接收方都支持文件传输存储和转发功能。
The original file transfer SIP INVITE shall include a CPIM/IMDN body requesting a delivery notification as described in section 3.3. Note that in this case no message is carried in the CPIM body. This allows the sender to request a delivery notification to confirm when the receiver gets the file.
原始文件传输SIP INVITE将包括请求传递通知的CPIM / IMDN主体，如第3.3节所述。请注意，在这种情况下，CPIM主体中不会携带任何消息。这允许发送方请求传送通知以确认接收方何时获得文件。
After the SIP INVITE is sent towards the receiver, the terminating FTF shall intercept the message before it is forwarded to the receiver (via normal IMS initial filter criteria already in place for RCS features) and store the file-transfer-id and the file-name SDP attributes defined in [RFC5547].
在向接收方发送SIP INVITE之后，终止FTF在将消息转发到接收方之前（经由用于RCS特征的正常IMS初始过滤标准）来截取该消息，并存储文件传输id和文件 - 名称在[RFC5547]中定义的SDP属性。
From this moment the terminating FTF shall forward the INVITE to the destination client, and can give a chance for the destination client to accept the File Transfer by waiting for a SIP response during a configured period of time.
从这一刻起，终止FTF应将INVITE转发到目的地客户端，并且可以给予目的地客户端在所配置的时间段期间等待SIP响应来接受文件传送的机会。 a) If the destination client accepts or refuses the file transfer, before the end of this configured period of time, the standard procedures apply with the precision given in step 5.
a) 如果目标客户端接受或拒绝文件传输，则在此配置的时间段结束之前，标准过程适用步骤5中给出的精度。 b) Otherwise, after the expiration of the corresponding configured timer, the terminating FTF shall cancel the SIP INVITE request towards the receiver by sending a SIP CANCEL. To make sure the receiver client understands that the reason for this cancellation is a timeout, a reason header shall be included as presented in the following table consistently with [RFC3326]:
b) 否则，在相应配置的定时器到期之后，终止FTF将通过发送SIP CANCEL来取消对接收器的SIP INVITE请求。为了确保接收方客户端理解该取消的原因是超时，应包括原因报头，如下表中与[RFC3326]一致：
```
Reason: SIP;cause=408;text="User not responding"
```
Table 33: Reason header in SIP CANCEL due to timeout / 表33：由于超时导致的SIP CANCEL中的原因头
c) If an error occurs that is listed in Table 32, the FTF shall also accept the file transfer on behalf of the destination user and store it.
c) 如果发生表32中列出的错误，则FTF还将代表目标用户接受文件传输并将其存储。
Please note that specifying when the FTF should accept the initial SIP INVITE and start storing the file transfer is outside the scope of this UNI specification and it is left up to Service Provider policy. Possible implementation choices are:
请注意，指定FTF应该接受初始SIP INVITE并开始存储文件传输的时间超出了UNI规范的范围，并且由服务提供商策略决定。可能的实现选择有：
- Accept the file transfer when the CANCEL is sent to the end user or an error is received (note that this is the option shown in the figures below).
  当CANCEL发送给最终用户或接收到错误时，接受文件传输（请注意，这是下图所示的选项）。
- Accept the file transfer as soon as the initial INVITE has been received.
  收到初始INVITE后立即接受文件传输。 If the transmission is interrupted from the sender (e.g. because of loss of connectivity), it is left up to the local policy of the FTF whether the received fragment remains stored and if so for what time or whether it is discarded. In case it is discarded (either immediately or after expiry) and the sender tries to resume the file transfer, the file transfer will be rejected as described in [RFC5547]. In that case the sender shall transmit the entire file again as described in section 3.5.4. A stored fragment of a File Transfer shall not be forwarded to the recipient until the sender has resumed the File Transfer and provided the remainder of the file.
  如果传输从发送方中断（例如，由于连接丢失），则根据FTF的本地策略，无论所接收的片段是否保持存储以及如果是，什么时间或者是否被丢弃。如果它被丢弃（立即或过期后），并且发送器尝试恢复文件传输，文件传输将被拒绝，如[RFC5547]中所述。在这种情况下，发送方将按照第3.5.4节所述重新发送整个文件。在发送方已恢复文件传输并提供文件的剩余部分之前，文件传输的存储片段不应转发给接收方。
When the destination client accepts the file transfer invitation by sending a SIP “200 OK”, the terminating FTF should always stay in the media path to be able to have a local copy of the file. How the local copy is performed is outside the scope of this specification and is up to each service provider. If the recipient client loses connectivity, the terminating FTF should complete the File Transfer on the incoming leg anyway in order to be able to, later, provide the file to any potential resume request from the recipient as per procedure defined in section 3.5.4.
当目的地客户端通过发送SIP“200 OK”来接受文件传输邀请时，终止FTF应该总是停留在媒体路径中以能够具有文件的本地副本。如何执行本地副本超出了本规范的范围，并且由每个服务提供商决定。如果接收方客户端失去连接，则终止FTF应当在入局支路上完成文件传输，以便能够按照第3.5.4节中定义的过程向接收方提供任何可能的恢复请求。
The local copy is only needed until the file is received by the recipient. The FTF shall delete the local copy, once the file has been completely received by the recipient.
只有在收件人接收到文件之前，才需要本地副本。一旦文件已被接收者完全接收，FTF将删除本地副本。

Figure 47: File transfer with store and forward via MSRP fetch on terminating service provider / 图47：在终止服务提供程序上通过MSRP提取存储和转发的文件传输

Figure 48: File transfer with store and forward via MSRP fetch on originating service provider / 图48：通过源服务提供程序上的MSRP提取存储和转发的文件传输

Please note the fetching procedure is covered in section 3.5.4.7.3.
请注意，提取过程在3.5.4.7.3节中介绍。

3.5.4.7.2 File transfer to offline users / 文件传输到离线用户

If supported by a service provider, files can be sent to users that are not online. This functionality can be provided by either the originating (senders) or terminating (receiver’s) service provider.
如果服务提供商支持，可以将文件发送给不在线的用户。该功能可以由始发（发送者）或终止（接收者）服务提供者提供。

On the originating client this can be enabled by having the FT CAP ALWAYS ON parameter (defined in Table 76 in section A.1.5) set to 1, indicating that the file transfer can take place even if the recipient is offline. This parameter should only be set to 1 if either:
在始发客户端上，可以通过将FT CAP ALWAYS ON参数（在A.1.5节中的表76中定义）设置为1来启用，这表示即使接收方脱机也可以进行文件传输。只有在以下情况下，此参数才应设置为1：

All the interconnected service providers support the file transfer store and forward feature, or,
所有互连的服务提供商支持文件传输存储和转发功能，或者，
Store and forward for files is provided as an originating function (sender’s FTF).
存储和转发文件作为始发功能（发送者的FTF）提供。

In this case, File Transfer shall be offered towards all users that are known to support the File Transfer service based on a prior capability exchange.
在这种情况下，将向已知基于先前能力交换支持文件传输服务的所有用户提供文件传输。

Also, when FT CAP ALWAYS ON is set to 0, the originating client may, based on a prior capability exchange, as described in section 2.6 be aware that the recipient that is offline supports Store and Forward for File Transfer. If FT CAP ALWAYS ON is set to 0 File Transfer shall not be offered to offline recipients that are not known to support Store and Forward for File Transfer.
此外，当FT CAP ALWAYS ON设置为0时，如2.6节所述，基于先前的能力交换，发起客户端可以知道离线的接收方支持用于文件传输的存储和转发。如果FT CAP ALWAYS ON设置为0，不应向不知道是否支持存储和转发文件传输的脱机收件人提供文件传输。

When initiating a File Transfer to an offline user, the client shall compose the file transfer SIP INVITE request as described in [RCS-SIMPLEIM-ENDORS] or [RCS-CPM- CONVFUNC-ENDORS] (depending on the used message technology) with following changes:
当向离线用户发起文件传输时，客户端应按照[RCS-SIMPLEIM-ENDORS]或[RCS-CPM-CONVFUNC-ENDORS]（取决于所使用的消息技术）所述，以如下改动方式撰写文件传输SIP INVITE请求：

It shall include a CPIM/IMDN body identical to that described for the chat/IM service in section 3.3.4.1 except that in this case a display notification is not requested and no message is carried.
它应包括与在第3.3.4.1节中针对聊天/ IM服务描述的CPIM / IMDN主体相同的CPIM / IMDN主体，除了在这种情况下不请求显示通知并且不携带消息。
It shall not include the FT thumbnail, since it is not known if the recipient or the recipient’s network has this capability.
它不应包括FT缩略图，因为不知道收件人或收件人的网络是否具有此功能。

There are two possible cases:
有两种可能的情况：

The receiver’s Service Provider supports the RCS File Transfer store and forward procedures and is aware that the receiver is offline or receives a SIP 408 Request Timeout or SIP 480 Temporary unavailable error when sending the request to the client, and therefore, accepts the file transfer on their behalf.
接收方的服务提供商支持RCS文件传输存储和转发过程，并且意识到接收方在向客户端发送请求时离线或接收到SIP 408请求超时或SIP 480临时不可用错误，并且因此为接收方的利益而接受文件传输。
- When the receiver’s FTF has detected that the receiver is back online (i.e. third party registration) the FTF forwards the SIP INVITE request without the CPIM/IMDN body. In order to support legacy devices, the file transfer SIP INVITE request shall carry the P-Asserted-Identity of the original sender, rather than the identity of the FTF that stored the message.
  当接收方的FTF检测到接收机恢复在线（即第三方注册）时，FTF转发不具有CPIM / IMDN主体的SIP INVITE请求。为了支持传统设备，文件传输SIP INVITE请求应该携带原始发送者的P-Asserted-Identity，而不是存储消息的FTF的标识。
- The receiver’s FTF will take the responsibility to issue the delivery notification back to the originator.
  接收方的FTF将负责将发送通知发送回发起方。
The sender’s Service Provider supports the RCS File Transfer store and forward procedures.
发件人的服务提供商支持RCS文件传输存储和转发过程。
- In this case, the FTF may not be able to detect when the user comes back online, and must therefore periodically retry to send the File Transfer SIP INVITE request to the recipient. The retry period and duration is determined by local Service Provider policy (see section 3.5.4.7.2.1).
  在这种情况下，FTF可能无法检测到用户何时恢复在线，因此必须定期重试向接收方发送文件传输SIP INVITE请求。重试周期和持续时间由本地服务提供商策略确定（参见第3.5.4.7.2.1节）。

From this point on, the standard file transfer procedure and the cases covered in the remaining sub-sections of section 3.5.4.7 apply.
从这一点开始，标准文件传输程序和第3.5.4.7节剩余子部分中涉及的情况适用。

Figure 49: File transfer with store and forward via MSRP for offline users (1/2) / 图49：离线用户通过MSRP存储和转发的文件传输（1/2）

Figure 50: File transfer with store and forward via MSRP for offline users (2/2) / 图50：离线用户通过MSRP存储和转发的文件传输（2/2）

3.5.4.7.2.1 File Transfer retries in originating network / 源网络中的文件传输重试

If the sender’s network provides store and forward functionality, the sender’s FTF will accept the File Transfer request if one of error responses listed in Table 32 is returned from the terminating network.
当发送者的网络提供存储和转发功能时，如果从终止网络返回表32中列出的错误响应之一，则发送者的FTF将接受文件传送请求。

In this case, the originating FTF shall attempt retries to deliver the file towards the receiver with the following procedures:
在这种情况下，始发FTF将尝试重试以向接收方传递文件，具有以下过程：

A normal file transfer SIP INVITE request is sent from the sender’s FTF to User B as described in [RCS-SIMPLEIM-ENDORS] or [RCS-CPM-CONVFUNC-ENDORS] (depending on the used message technology) with following changes:
如[RCS-SIMPLEIM-ENDORS]或[RCS-CPM-CONVFUNC-ENDORS]（取决于所使用的消息技术）中所述，正常文件传输SIP INVITE请求从发送者的FTF发送到用户B，具有以下改变：
- The SIP INVITE contains file transfer feature tag and the identity of the original sender in the P-Asserted-Identity header.
  SIP INVITE包含文件传输功能标签和P-Asserted-Identity头中的原始发件人的身份。
- This SIP INVITE shall be sent without the CPIM/IMDN body containing the delivery notification request (i.e. like in the case of a file transfer without the store and forward functionality).
  该SIP INVITE将在没有包含传递通知请求的CPIM / IMDN主体的情况下被发送（即，在没有存储和转发功能的文件传输的情况下）。
When the receiver’s device is online and the user accepts the File Transfer, the file shall be transferred.
当接收者的设备在线并且用户接受文件传送时，文件将被传送。
When the file is delivered, the FTF shall issue the delivery notification back to the originator and should delete the stored copy of the file.
当文件交付时，FTF应将发送通知发回给发起者，并应删除存储的文件副本。
If the receiver’s device is not available, a 480 Temporary Unavailable error can be expected. If that or another error listed in Table 32 occurs:
如果接收器的设备不可用，则可能会出现480临时不可用错误。如果发生表32中列出的或另一个错误：
- The sender’s FTF re-tries with step 1 after a Service Provider configurable amount of time.
  在服务提供者可配置的时间量之后，发送者的FTF重新尝试步骤1。
If the Service Provider defined number of retries or amount of time has elapsed or a SIP 603 Decline response is received, the undelivered files are discarded, and the sender is notified if requested.
如果服务提供商定义的重试次数或时间量已过，或者收到SIP 603拒绝响应，则丢弃未传递的文件，如果请求通知发送方。

3.5.4.7.3 Client behaviour and file fetching / 客户端行为和文件提取

After receiving the cancellation (protocol-cause 408 in the Reason header field indicating that store and forward took place), the RCS client shall try to fetch the file as presented below:
在接收到取消（在Reason报头字段中指示存储和转发发生的protocol-cause 408）后，RCS客户端将尝试获取文件，如下所示：

The receiver client/device implementation, knowing that the original SIP INVITE is expired, shall fetch the file from the FTF. In order to identify the requested file uniquely the client shall:
知道原始SIP INVITE已过期的情况下，接收方客户端/设备实现将从FTF获取文件。为了唯一地识别所请求的文件，客户应该：
a) Use the same SDP file-transfer-id that was used in the original SIP INVITE
a) 使用在原始SIP INVITE中使用的相同的SDP文件传输标识
b) Use the same SDP file-name that was used in the original SIP INVITE.
b) 使用与原始SIP INVITE中使用的相同的SDP文件名。

Figure 51: File transfer store and forward via MSRP on terminating FTF fetch / 图51：在终止FTF提取时文件传输存储和转发通过MSRP

Figure 52: File transfer store and forward via MSRP on originating FTF fetch / 图52：通过原始FTF提取上的MSRP进行文件传输存储和转发
The server will remove the file once it is successfully downloaded.
一旦成功下载，服务器将删除该文件。
After the file is successfully downloaded, a SIP MESSAGE containing the delivered notification will be issued to the sender to confirm the destination got the file.
在成功下载文件之后，将向发送方发出包含所传送通知的SIP MESSAGE，以确认目标获得该文件。

3.5.4.7.4 Timing between originating and terminating store and forward / 始发和终止存储和转发之间的计时

When implementing store and forward, the timing to trigger the store and forward procedure shall take into account whether store and forward is supported on the terminating side, the timer (or time to trigger the error that signals store and forward is required) shall be significantly smaller than the timer used on the originating store and forward process. Consequently, the following recommendations shall be followed:
当实现存储和转发时，触发存储和转发过程的定时应考虑在终止侧是否支持存储和转发，定时器（或需要信号存储和转发的错误的触发时间）应明显地小于在始发存储和转发过程中使用的定时器。因此，应遵循以下建议：

The timer on the originating side should be greater than a half the SIP INVITE timeout period.
发端的定时器应该大于SIP INVITE超时周期的一半。
The timer on the terminating side (or time to trigger the error) should be smaller than a quarter the SIP INVITE timeout period.
终止侧的定时器（或触发错误的时间）应该小于SIP INVITE超时周期的四分之一。

3.5.4.7.5 File transfer procedures without store and forward / 没有存储和转发的文件传输过程

Following the capability exchange and assuming both sender and receiver support the store and forward procedures, there are two possible scenarios where the file transfer procedure does not require a store and forward:
在能力交换和假设发送方和接收方都支持存储和转发过程之后，存在两种可能的情况，其中文件传输过程不需要存储和转发：

If the receiver accepts before the SIP INVITE expiration, then the file transfer takes place as normal:
如果接收者在SIP INVITE过期之前接受，则文件传输如常进行：
a) The MSRP session is established to perform the file transfer.
a) 建立MSRP会话以执行文件传输。
b) When completed a SIP BYE is exchanged to terminate the session.
b) 当完成时，交换SIP BYE以终止会话。
c) Please note that the original file SIP INVITE is modified to include a CPIM/IMDN body identical to that described for the chat/IM service in section 3.3 except for the fact that in this case a message is not carried and a display notification is never requested. This allows the sender to request a delivery notification to confirm when the receiver gets the file. In this case, as no store and forward takes place, the receiver client is responsible to issue a SIP MESSAGE containing the CPIM/IMDN notification that the file has been successfully delivered.
c) 请注意，原始文件SIP INVITE被修改为包括与第3.3节中针对聊天/ IM服务所描述的CPIM / IMDN主体相同的CPIM / IMDN主体，除了在这种情况下不携带消息并且从不请求显示通知的事实。这允许发送方请求传送通知以确认接收方何时获得文件。在这种情况下，由于没有存储和转发，接收器客户端负责发出包含CPIM / IMDN通知的SIP MESSAGE文件已成功传送。

Figure 53: File transfer without store and forward: Receiver accepts file before timeout / 图53：没有存储和转发的文件传输：Receiver在超时前接受文件
If the receiver rejects before the SIP INVITE expiration, then a 603 Decline response is sent to the sender and the file transfer is cancelled.
如果接收者在SIP INVITE到期之前拒绝，则向发送者发送603拒绝响应，并且取消文件传送。

Figure 54: File transfer without store and forward: Receiver rejects file before timeout / 图54：没有存储和转发的文件传输：接收器在超时前拒绝文件

3.5.4.7.6 CPIM/IMDN delivery notifications / CPIM/IMDN传送通知

The same mechanism used for the 1-to-1 chat described in section 3.3.4 specification shall be used with the following changes:
用于3.3.4规范中描述的1对1聊天的相同机制应该与以下更改一起使用：

The notifications shall always be sent using a SIP MESSAGE.
通知应始终使用SIP MESSAGE发送。
The IMDN disposition shall ONLY include a delivery notification (request or response depending on the case) and never request or generate a displayed notification.
IMDN处置应仅包括传递通知（根据情况的请求或响应），并且不要求或生成所显示的通知。

3.5.4.8 File Transfer via HTTP / 通过HTTP进行文件传输

As presented in the previous sections, the default mechanism to transfer files in RCS is based in a MSRP transfer.
如前面部分所述，在RCS中传输文件的默认机制基于MSRP传输。

The present section proposes an alternative mechanism where the file transfer is based in storing the file in a publicly available server and then sharing the location using standalone messaging and the 1-to-1 and Group Chat procedures described in sections 3.2, 3.3 and 3.4. Message revocation procedures as described in section 3.3.4.1.10, do not apply for 1- to-1 Chat messages carrying the location where the file is stored. The same applies for all services that utilise File Transfer via HTTP mechanism (e.g. audio messaging). The main motivations behind this procedure presented below:
本节提出了一种替代机制，其中文件传输基于将文件存储在公共可用的服务器中，然后使用独立消息传递和第3.2,3.3和3.4节中描述的1对1和群聊过程共享位置。第3.3.4.1.10节中描述的消息撤销过程不适用于携带文件存储位置的1对1聊天消息。这同样适用于利用通过HTTP机制的文件传输（例如音频消息）的所有服务。此过程的主要动机如下所示：

Through the re-use of the procedures for RCS messaging (standalone messaging and chat), the HTTP file transfer mechanism shall automatically benefit from the store and forward mechanism available for chat meaning there is no need to specify additional store and forward procedures.
通过重新使用RCS消息（独立消息和聊天）的过程，HTTP文件传输机制将自动受益于可用于聊天的存储和转发机制，这意味着不需要指定附加的存储和转发过程。
HTTP is a quite mature protocol broadly supported for many years in the majority of terminals. This procedure shall, therefore, benefit from its availability and resiliency.
HTTP是相当成熟的协议，在大多数终端中广泛支持多年。因此，该程序应受益于其可用性和弹性。

3.5.4.8.1 Configuration and capability exchange / 配置和能力交换

In order to guarantee back compatibility, the file transfer via HTTP procedure shall be only used instead the MSRP procedure if:
为了保证后向兼容性，只有在以下情况下才使用通过HTTP过程的文件传输而不是MSRP过程：

The sender is adequately configured to use this procedure which is verified by checking that the FT HTTP CS URI, FT HTTP CS USER and FT HTTP CS PWD configuration parameters (all defined in Table 76 in section A.1.5) are correctly set in the configuration received by the file sending client.
发送方被适当地配置为使用该过程，该过程检查在文件发送客户端接收的配置文件中，FT HTTP CS URI，FT HTTP CS USER和FT HTTP CS PWD配置参数（全部在表A.1.5中的表76中定义）是否被正确地设置来进行验证。
Both sender and receiver support the procedure by verifying that the File Transfer via HTTP capability defined in section 2.6.1 is present in the RCS capabilities on both ends.
发送方和接收方都通过验证第2.6.1节中定义的通过HTTP能力的文件传输在两端的RCS能力中存在来支持该过程。
An RCS client shall only make this capability available if the service is supported by the implementation and the configuration parameters FT HTTP CS URI, FT HTTP CS USER and FT HTTP CS PWD are correctly set. In this case the RCS client shall also include the File Transfer via HTTP IARI tag defined in section 2.6.1.1.2 in the Contact header of the SIP INVITE requests and SIP 200 OK responses that it sends during the setup of a Group Chat.
如果服务由实现支持并且配置参数FT HTTP CS URI，FT HTTP CS USER和FT HTTP CS PWD已正确设置，则RCS客户端将仅使此功能可用。在这种情况下，RCS客户端还应包括在设置群聊期间发送的SIP INVITE请求和SIP 200 OK响应的联系人头中的第2.6.1.1.2节中定义的HTTP IARI标签的文件传输。
The FT DEFAULT MECH configuration parameter (defined in Table 76 in section A.1.5) is set to HTTP.
FT DEFAULT MECH配置参数（在A.1.5节中的表76中定义）设置为HTTP。

NOTE: As described in section A.1.5, the FT HTTP CS URI, FT HTTP CS USER and FT HTTP CS PWD configuration parameters could be considered to have been correctly set if they have not been provisioned in case the operator wants to rely on the defaults for those parameters.
注意：如第A.1.5节所述，如果FT HTTP CS URI，FT HTTP CS USER和FT HTTP CS PWD配置参数没有设置，则可以认为它们已正确设置，以防运营商希望依赖于这些参数的默认值。

If both ends support the procedure, all file transfer shall be performed using the new procedure described in this and the following sections. If not, the file transfer via MSRP procedures described 3.5.4 shall be employed.
如果两端都支持该过程，则应使用本节和以下各节中描述的新过程执行所有文件传输。如果没有，则应采用文件传输通过描述3.5.4的MSRP程序。

When both ends are in chat or group chat session the capability shall be available if following conditions are fulfilled:
当两端都在聊天或群聊会话中时，如果满足以下条件，则该能力可用：

The application/vnd.gsma.rcs-ft-http+xml content type is indicated in the a=accept- wrapped-types attribute during the SDP negotiation and,
application/vnd.gsma.rcs-ft-http+xml内容类型在SDP协商期间在a=accept-wrapped-types属性中指示，并且，
For the case of a 1-to-1 chat, the contact is known to support the File Transfer via HTTP capability based on a capability exchange or on the cached result of an earlier capability exchange when a capability exchange doesn’t provide a conclusive result and,
对于1对1聊天的情况，已知联系人基于能力交换通过HTTP能力支持文件传输，或者当能力交换不提供结论性结果时支持早先能力交换的缓存结果，并且，
For the case of a Group Chat, the Contact header field received during the setup of that Chat included the File Transfer via HTTP IARI tag defined in section 2.6.1.1.2.
对于群聊的情况，在该聊天的设置期间接收的联系人头部字段包括通过在部分2.6.1.1.2中定义的HTTP IARI标签的文件传送。
A conference focus supporting File Transfer via HTTP shall therefore indicate this support by including the File Transfer via HTTP IARI tag defined in section 2.6.1.1.2 in the Contact Header field of the SIP INVITE and SIP 200 OK responses that it sends during the setup of the Group Chat. When one of the participants in the Chat initiates a File Transfer via HTTP, the conference focus shall not forward the File Transfer via HTTP body to participants that did not include the File Transfer via HTTP IARI tag in the Contact header that they provided during the setup of the Group Chat.
因此，通过HTTP支持文件传输的会议焦点将通过以下方式声明对此的支持，即是在群聊的设置期间，通过在2.6.1.1.2节中定义的HTTP IARI标签，将文件传输包括在SIP INVITE和SIP 200 OK的Contact头字段中。在群聊的设置期间，当聊天中的一个参与者启动通过HTTP的文件传输时，会议焦点不应通过HTTP主体将文件传输转发给这样的参与者，即提供的Contact头中不包含通过HTTP IARI标记的文件传输。

3.5.4.8.2 Offline users / 离线用户

RCS client shall allow the file transfer via HTTP even the receiver is offline when:
RCS客户端将允许通过HTTP进行文件传输，即使接收者在以下情况下脱机：

IM CAP ALWAYS ON configuration parameter (defined in sections A.1.4.3) is set to enabled (1), and,
IM CAP ALWAYS ON配置参数（在A.1.4.3节中定义）设置为enabled（1），并且，
The receiver user is known to support the file transfer over HTTP capability (cached from the previous exchange).
已知接收者用户支持通过HTTP能力的文件传输（从先前的交换缓存）。

3.5.4.8.3 File transfer procedure / 文件传输过程

3.5.4.8.3.1 Sender procedures / 发送者程序

NOTE: In this whole section, it is assumed that the sender has the FT DEFAULT MECH configuration parameter (see section A.1.5) is set to HTTP.
注意：在这整个部分，假设发送方具有FT DEFAULT MECH配置参数（参见第A.1.5节）并设置为HTTP。

After the capability exchange takes place, it is verified whether both the sender and the receiver support the file transfer via HTTP procedure (as described in section 3.5.4.8.1 and 3.5.4.8.2).
在能力交换发生后，验证发送者和接收者是否都通过HTTP过程支持文件传输（如第3.5.4.8.1和3.5.4.8.2节所述）。
Assuming both ends support it, the sender shall first send an empty HTTP POST[32] request (i.e. a request without any body) to the FT HTTP CS URI. If the client supports authentication with an GBA bootstrapped security association as defined in [3GPP TS 33.220] it shall indicate this by addition of a GBA product token in the User-Agent header as defined in [3GPP TS 24.109]. This request shall result in any of following responses:
假设两端都支持它，发送方应首先向FT HTTP CS URI发送空的HTTP POST [32]请求（即没有任何主体的请求）。如果客户端支持具有[3GPP TS 33.220]中定义的GBA引导安全关联的认证，则其将通过在如[3GPP TS 24.109]中定义的User-Agent报头中添加GBA产品令牌来指示这一点。此请求应导致以下任何响应：

[32] This specification uses the term “HTTP POST” and “HTTP GET” as a generic reference to the action of using the POST or GET methods of HTTP. However, it is strongly recommended that whenever the POST action contains sensitive information such as a user ID or password, the action should take place over a secure connection and/or via HTTPS explicitly. This is enforced by the service provider by configuring a FT HTTP CS URI with "https" schema.
[32] 本规范使用术语“HTTP POST”和“HTTP GET”作为对使用HTTP的POST或GET方法的操作的一般参考。但是，强烈建议每当POST操作包含敏感信息（例如用户ID或密码）时，操作应通过安全连接和/或通过HTTPS显式进行。这是由服务提供者通过配置具有“https”模式的FT HTTP CS URI来实现的。
- a) A HTTP 401 AUTHENTICATION REQUIRED error response carrying a WWW-Authenticate header field as defined in [RFC2616] if authentication is required.
  如果需要认证，则携带如[RFC2616]中定义的WWW-Authenticate报头字段的HTTP 401 AUTHENTICATION REQUIRED错误响应。
  If the client and the service provider's HTTP content server supports GBA based authentication then the server returns an HTTP 401 AUTHENTICATION REQUIRED response with an WWW Authenticate header instructing the client to use HTTP digest Authentication with a bootstrapped security association. In this case, the client shall authenticate with the bootstrapped security association as defined in [3GPP TS 24.109]. If the client has no bootstrapped security association in place it shall invoke the bootstrapping procedure defined in [3GPP TS 24.109].
  如果客户端和服务提供商的HTTP内容服务器支持基于GBA的认证，则服务器返回带有WWW认证报头的HTTP 401 AUTHENTICATION REQUIRED响应，指示客户端使用带有自举安全关联的HTTP摘要认证。在这种情况下，客户端将使用[3GPP TS 24.109]中定义的自举安全关联进行认证。如果客户端没有引导的安全关联，它将调用[3GPP TS 24.109]中定义的引导过程。
  Otherwise, the client and the server shall authenticate with the values of FT HTTP CS USER and FT HTTP CS PWD from the device configuration as defined in Table 76 in section A.1.5.
  否则，客户端和服务器将根据A.1.5节中表76中定义的设备配置使用FT HTTP CS USER和FT HTTP CS PWD的值进行身份验证。
- b) A HTTP 204 NO CONTENT response if authentication is not required
  如果不需要认证，则为HTTP 204 NO CONTENT响应
- c) A HTTPS 503 INTERNAL ERROR with retry-after header if the server is busy and cannot handle the request. The RCS client shall in this case retry to upload after the time specified in the retry-after header.
  如果服务器正忙，并且无法处理请求，则使用retry-after标头的HTTPS 503 INTERNAL ERROR。在这种情况下，RCS客户端将在重试后报头中指定的时间后重试上传。
- d) Any other response, the RCS client shall retry the request in this case.
  任何其他响应，RCS客户端将在这种情况下重试请求。
The sender shall then upload the file to the HTTP content server by making a HTTPS POST request to the FT HTTP CS URI to upload the file containing the following elements:
然后，发送方通过向FT HTTP CS URI发出HTTPS POST请求，上传包含以下元素的文件，将文件上传到HTTP内容服务器：
- A file transfer Transaction ID (TID): this TID is optional and is included in case the client supports the optional resume of the file upload as described in section 3.5.4.8.3.1.1. The TID value shall be a unique ID generated by the client according to [RFC4122] section 4.2;
  文件传输事务ID（TID）：此TID是可选的，包含在客户端支持文件上传的可选恢复的情况下，如第3.5.4.8.3.1.1节所述。 TID值应是客户端根据[RFC4122]第4.2节生成的唯一ID;
- The thumbnail content: This is optional as it is only required for images and videos as per the procedures described in section 3.5.4;
  缩略图内容：这是可选的，因为它只需要图像和视频按照3.5.4节中描述的过程;
- The file content.
  文件内容。
In order to carry these elements, the HTTP POST method shall contain a MIME multipart/form-data entity body with the following parts that shall be transmitted in the listed order:
为了携带这些元素，HTTP POST方法应包含具有以下部分的MIME多部分/表单数据实体主体，应按列出的顺序发送：
- An optional one containing the transaction ID:
  一个可选的包含事务ID的实体：
```
Content-Disposition: form-data; name="tid” 
Content-Type: text/plain

<Transaction-ID generate by the client>
```
Table 34: First form of the HTTP POST method request to upload the file to the HTTP content server (Transaction ID) / 表34：将文件上载到HTTP内容服务器的HTTP POST方法请求的第一种形式（事务ID）
- An optional one containing the thumbnail:
  一个可选的包含缩略图的实体：
```
Content-Disposition: form-data; name="Thumbnail"; filename="<local_filename>"
Content-Type: [mime type depending on the thumbnail; e.g. image/jpeg]

<Thumbnail content>
```
Table 35: Second form of the HTTP POST method request to upload the file to the HTTP content server (Thumbnail contents) / 表35：HTTP POST方法请求将HTTP文件上传到HTTP内容服务器的第二种形式（缩略图内容）
- One containing the file:
  一个包含文件的实体：
```
Content-Disposition: form-data; name="File"; filename="<local_filename>"
Content-Type: [mime type depending on the file; e.g. image/jpeg]

<file content>
```
Table 36: Third form of the HTTP POST method request to upload the file to the HTTP content server (file contents) / 表36：第三种形式的HTTP POST方法请求将文件上传到HTTP内容服务器（文件内容）
The client should include the Content-Length header to indicate the size of the HTTP request body, as described in [RFC7230]. If present, the Content-Length indicate the size of HTTP POST body part, i.e. the multipart/form-data entity body.
客户端应该包括Content-Length报头来指示HTTP请求主体的大小，如[RFC7230]中所述。如果存在，Content-Length指示HTTP POST主体部分的大小，即multipart/form-data实体主体。
If the client received a HTTP 204 NO CONTENT response in step 2, then it shall not add an authorization header to the HTTP POST request.
如果客户端在步骤2中接收到HTTP 204 NO CONTENT响应，则它不会向HTTP POST请求添加授权头。
If the client received a HTTP 401 AUTHENTICATION REQUIRED response in step 2, with a WWW-Authenticate response header instructing the client to apply basic or digest authentication, then the client shall add an Authorization header to the HTTP POST request in accordance with the requested authentication scheme as per [RFC2617] using the FT HTTP CS USER and FT HTTP CS PWD configuration parameters as credentials.
如果客户端在步骤2中接收到HTTP 401 AUTHENTICATION REQUIRED响应，其中WWW认证响应报头指示客户端应用基本或摘要认证，则客户端将根据所请求的认证向HTTP POST请求添加授权报头方案根据[RFC2617]使用FT HTTP CS USER和FT HTTP CS PWD配置参数作为凭证。
If the client received a HTTP 401 AUTHENTICATION REQUIRED response in step 2, with a WWW-Authenticate response header instructing the client to apply digest authentication with a bootstrapped security association, then the client shall use the stored key material and the B-TID to generate keys specific to the HTTP content server as defined in [3GPP TS 33.220]. The client shall add an Authorization header to the HTTP POST request generated from the key material and the B-TID .
如果客户端在步骤2中接收到HTTP 401 AUTHENTICATION REQUIRED响应，其中WWW认证响应报头指示客户端使用引导安全关联应用摘要认证，则客户端将使用所存储的密钥材料和B-TID来生成如[3GPP TS 33.220]中定义的特定于HTTP内容服务器的密钥。客户端将向从密钥材料和B-TID生成的HTTP POST请求添加授权报头。
The client shall send the HTTP POST request to the HTTP content server.
客户端必须向HTTP内容服务器发送HTTP POST请求。
There are two possible cases:
有两种可能的情况：
- a) If the upload is successful, the client shall get a HTTPS 200 OK response containing a XML in the body that specifies:
  a) 如果上传成功，客户端将获得一个HTTPS 200 OK响应，在主体中包含一个XML，指定：
  - i. The URL, size, content type and validity for the thumbnail, if applicable.
    i. 缩略图的网址，大小，内容类型和有效性（如果适用）。
  - ii. The URL, size, filename, content type and validity for the file.
    ii. 文件的URL，大小，文件名，内容类型和有效性。
```
<?xml version="1.0" encoding="UTF-8"?>
<file xmlns="urn:gsma:params:xml:ns:rcs:rcs:fthttp">
 <file-info type="thumbnail">
   <file-size>[thumbnail size in bytes]</file-size>
   <content-type>[MIME-type for thumbnail]</content-type>
   <data url = "[HTTP URL for the thumbnail]" until = "[validity of the thumbnail]"/>
 </file-info>
 <file-info type="file">
   <file-size>[file size in bytes]</file-size>
   <file-name>[original file name]</file-name>
   <content-type>[MIME-type for file]</content-type>
   <data url = "[HTTP URL for the file]" until = "[validity of the file]"/>
 </file-info>
<file>
```
  Table 37: HTTP content server response: XML contained in the body / 表37：HTTP内容服务器响应：主体中包含的XML
  
  Please note that referring to the XML body in Table 37:
  请注意，参考表37中的XML主体：
  - The thumbnail part is only included if the sender uploaded a thumbnail to the server.
    仅当发件人向服务器上传缩略图时，才包括缩略图部分。
  - The validity of the files shall be specified by providing the date the files shall be removed on the server using the [ISO8601] format including the date and time in UTC (Coordinated Universal Time) time zone (e.g. 2007-04-05T14:30:00Z). The validity depends on the configuration the originating Service Provider has set on the HTTP content server.
    文件的有效性应通过提供文件在服务器上使用[ISO8601]格式（包括UTC（协调世界时）时区中的日期和时间）（例如2007-04-05T14:30:00Z）。有效性取决于始发服务提供商在HTTP内容服务器上设置的配置。
  During the upload process the RCS client shall show the user the progress of the upload as in the case for the file transfer via MSRP.
  在上传过程中，RCS客户端应向用户显示上传的进度，如通过MSRP进行文件传输的情况。
- b) If the upload is not successful, there are two cases to consider:
  b) 如果上传不成功，有两种情况需要考虑：
  - i. If the server is busy and cannot handle the request a HTTPS 503 INTERNAL ERROR with retry-after header. The RCS client shall retry to upload after the time specified in the retry-after header.
    i. 如果服务器忙，并且无法处理请求，则使用带有retry-after标头的HTTPS 503 INTERNAL ERROR。 RCS客户端将在重试后报头中指定的时间后重试上传。
  - ii. If any other error, the RCS client shall automatically retry the upload as described in section 3.5.4.8.3.1.1 up to a maximum of three times.
    ii. 如果有任何其他错误，RCS客户端将自动重试上传，如第3.5.4.8.3.1.1节所述，最多三次。
When the upload in step 4 was successful, the sender shall then send a message to the receiver(s) with the following content:
当步骤4中的上传成功时，发送方应向具有以下内容的接收方发送消息：
```
<?xml version="1.0" encoding="UTF-8"?>
<file xmlns="urn:gsma:params:xml:ns:rcs:rcs:fthttp">
 <file-info type="thumbnail">
   <file-size>[thumbnail size in bytes]</file-size>
   <content-type>[MIME-type for thumbnail]</content-type>
   <data url = "[HTTP URL for the thumbnail]" until = "[validity of the thumbnail]"/>
 </file-info>
 <file-info type="file" file-disposition="[file-disposition]">
   <file-size>[file size in bytes]</file-size>
   <file-name>[original file name]</file-name>
   <content-type>[MIME-type for file]</content-type>
   <data url = "[HTTP URL for the file]" until = "[validity of the file]"/>
 </file-info>
<file>
```
Table 38: File transfer via HTTP message body content / 表38：通过HTTP消息体内容传输文件

Where compared to the body received from the content server (i.e. Table 37), an (optional) attribute has been added:
在与从内容服务器接收的主体（即表37）相比，添加了（可选）属性：
- The file-disposition attribute to the file-info element of the main file: This optional attribute provides functionality similar to the File-Disposition SDP attribute in file transfer via MSRP which is described in [RFC5547] and can take the same values (i.e. render and attachment). If the attribute is not included attachment shall be used as the default value.
  主文件的file-info元素的文件处理属性：该可选属性提供类似于文件传输中的文件处理SDP属性的功能，该文件传输通过[RFC5547]中描述的MSRP，并且可以采用相同的值（即，render 和attachment）。如果不包括属性，则附件应被用作默认值。
  
  NOTE: Independently of the mechanism used to transport the message (standalone message or chat), a CPIM body will be used. As the content is now an XML, the CPIM content-type property shall be application/vnd.gsma.rcs-ft-http+xml.
  注意：与用于传输消息的机制（独立消息或聊天）无关，将使用CPIM主体。由于内容现在是XML，CPIM内容类型属性应为application/vnd.gsma.rcs-ft-http+xml。
If sending to a single user, there are two possible scenarios:
如果发送到单个用户，则有两种可能的情况：
- If there is a 1-2-1 chat session established with the user and File Transfer via HTTP is supported in the session as described in section 3.5.4.8.1, the session shall be reused to convey the content shown in Table 38 in a chat message.
  如果有与用户建立的1-2-1聊天会话，并且在3.5.4.8.1节中描述的会话中支持通过HTTP进行文件传输，则会话将被重用以在聊天消息中传送表38中所示的内容。
- There is no session established:
  没有建立会话：
  - If the RCS client is configured to use standalone messaging and the recipient supports standalone messaging as well, the mentioned message body shall be delivered using a standalone message carrying a dedicated Accept- Contact header field that includes the File Transfer via HTTP IARI tag defined in section 2.6.1.1.2 along with require and explicit parameters.
    如果RCS客户端被配置为使用独立消息传递，并且接收者也支持独立消息传递，则所述消息体将使用携带专用Accept-Contact首部字段的独立消息传递，该字段包括文件传输，该文件传输通过2.6.1.1.2节定义的HTTP IARI标签以及必须和显式的参数定义。
  - If standalone messaging is not supported by at least one of the parties, then a 1-to-1 Chat Session shall be established as specified in section 3.3.4. The RCS client shall include a dedicated Accept-Contact header field that includes the File Transfer via HTTP IARI tag defined in section 2.6.1.1.2 along with require and explicit parameters in the SIP INVITE request that it generates to establish this Chat session. The XML message shall be relayed in this session as follows:
    如果至少一方不支持独立消息传递，则应按照第3.3.4节的规定建立1对1聊天会话。 RCS客户端应包括一个专用的Accept-Contact头字段，它包括在第2.6.1.1.2节中定义的通过HTTP IARI标签的文件传送，以及它生成的建立此聊天会话的SIP INVITE请求中的必需和显式的参数。 XML消息在本会话中应如下传递：
    - If the configuration allows including the initial chat message in the SIP INVITE for a 1-2-1 chat, then it shall be used to carry the message.
      如果配置允许在用于1-2-1聊天的SIP INVITE中包括初始聊天消息，则其将用于携带消息。
    - If not, the file shall not be sent until the chat session is established.
      如果没有，则在聊天会话建立之前不会发送文件。
      
      NOTE: The inclusion of the Accept-Contact header field is only intended to guarantee that the request is routed to devices capable of File Transfer via HTTP. On the receiver’s side this request can be handled as a regular invitation for Chat.
      注意：包含Accept-Contact头字段仅用于保证请求路由到能够通过HTTP进行文件传输的设备。在接收方，此请求可以作为常规聊天邀请处理。
If sending to multiple users, there are two possible scenarios:
如果发送给多个用户，有两种可能的情况：
- If the file is to be transferred in an existing group chat, the session shall be reused to convey the content described in Table 38 in a chat message. If the Group Chat is closed due to inactivity, it shall be restarted first.
  如果文件要在现有的群聊中传送，则会话将被重用以在聊天消息中传达表38中描述的内容。如果群聊由于不活动而关闭，则应首先重新启动。
- There is no session established:
  没有建立会话：
  - If the RCS client is configured to use standalone messaging and prior verification that all participants support standalone messaging, the mentioned XML message body shall be delivered using a standalone message with multiple recipients carrying a dedicated Accept-Contact header field that includes the File Transfer via HTTP IARI tag defined in section 2.6.1.1.2 along with require and explicit parameters.
    如果RCS客户端被配置为使用独立消息传递和先前验证，所有参与者支持独立消息传递，则所提及的XML消息主体应使用具有多个接收者的独立消息传递，该接收者携带专用的Accept-Contact首部字段，其包括通过HTTP的文件传输 IARI标记在2.6.1.1.2节中定义，带有必须和显式的参数。
  - If standalone messaging is not enabled a group chat session shall be established first with all the participants before sending it as a message.
    如果未启用独立消息传递，则在将其作为消息发送之前，首先与所有参与者建立群组聊天会话。
When establishing a Chat Session, clients shall indicate their support for this File Transfer mechanism by including the application/vnd.gsma.rcs-ft-http+xml in the accept-wrapped-types attribute in the SDP that they provide as body in the SIP INVITE request or 200 OK response they send to take part in the Chat and include the File Transfer via HTTP IARI tag defined in section 2.6.1.1.2 in the Contact header field of that request/response. This will ensure that the conference focus does not forward the body to clients that do not support the mechanism as described in section 3.5.4.8.1.
当建立聊天会话时，客户端应通过在SDP中的accept-wrapped-types属性中包含application/vnd.gsma.rcs-ft-http+xml来指示他们对此文件传输机制的支持， SIP INVITE请求或200 OK响应，并且包括通过在请求/响应的联系人报头字段中的部分2.6.1.1.2中定义的HTTP IARI标签的文件传输。这将确保会议的重点不会将机构转给不支持第3.5.4.8.1节所述机制的客户。
The use in the client UI of the delivery notification coming from the receiver when the chat message containing the XML is delivered is left up to the RCS client implementation.
当包含XML的聊天消息被递送时，在客户端UI中使用来自接收者的递送通知留给RCS客户端实现。

Figure 55: File transfer via HTTP: Sender procedures / 图55：通过HTTP进行文件传输：发件人程序

Both the XML body returned by the HTTP Content Server and the optionally extended one that is exchanged between the clients shall correspond to following XML Schema which may be extended further by specific implementations and future versions of this specification. Such extensions shall be ignored by clients that are not aware of them:
由HTTP内容服务器返回的XML主体和在客户端之间交换的可选扩展XML体将对应于以下XML模式，其可以通过本说明书的特定实现和未来版本进一步扩展。此类扩展将被不了解它们的客户忽略：

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:gsma:params:xml:ns:rcs:rcs:fthttp" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:gsma:params:xml:ns:rcs:rcs:fthttp" elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:element name="file">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="file-info" minOccurs="1" maxOccurs="2">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="file-size">
                <xs:simpleType>
                  <xs:restriction base="xs:integer"/>
                </xs:simpleType>
              </xs:element>
              <xs:element name="file-name" minOccurs="0" maxOccurs="1">
                <xs:simpleType>
                  <xs:restriction base="xs:string"/>
                </xs:simpleType>
              </xs:element>
              <xs:element name="content-type">
                <xs:simpleType>
                  <xs:restriction base="xs:string"/>
                </xs:simpleType>
              </xs:element>
              <xs:element name="data">
                <xs:complexType>
                  <xs:attribute name="url" type="xs:anyURI" use="required"/>
                  <xs:attribute name="until" type="xs:dateTime" use="required"/>
                  <xs:anyAttribute namespace="##other" processContents="lax"/>
                </xs:complexType>
              </xs:element>
              <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:attribute name="type" use="required">
              <xs:simpleType>
                <xs:restriction base="xs:string">
                  <xs:enumeration value="file"/>
                  <xs:enumeration value="thumbnail"/>
                </xs:restriction>
              </xs:simpleType>
            </xs:attribute>
            <xs:attribute name="file-disposition" use="optional">
              <xs:simpleType>
                <xs:restriction base="xs:string">
                  <xs:enumeration value="render"/>
                  <xs:enumeration value="attachment"/>
                </xs:restriction>
              </xs:simpleType>
            </xs:attribute>
            <xs:anyAttribute namespace="##other" processContents="lax"/>
          </xs:complexType>
        </xs:element>
        <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Table 39: File transfer via HTTP message body schema / 表39：通过HTTP消息体模式的文件传输

# 3.5.4.8.3.1.1 Upload Resume / 上传恢复

In case a file upload cannot be completed, e.g. because the file sender loses network coverage, the RCS client should allow to resume the File Transfer by using the procedure described in this section. It is intended to resume the upload of the file itself but not of an optional thumbnail which has small size. The content server shall store partial uploads and make them accessible via the related TID defined in 3.5.4.8.3.1. As it may apply a service provider policy and remove partially uploaded files after some time, resume upload may just be possible for a limited time. In case it fails, the upload cannot be resumed and the complete file needs to be uploaded again following the procedure in section 3.5.4.8.3.1. The following operations are used:
如果文件上传无法完成，例如由于文件发送方丢失网络覆盖，RCS客户端应允许使用本节中描述的过程恢复文件传输。它旨在恢复文件本身的上传，而不是具有小尺寸的可选缩略图的上载。内容服务器应存储部分上传，并通过3.5.4.8.3.1中定义的相关TID访问。由于可能应用服务提供商策略并在一段时间后删除部分上传的文件，因此恢复上传可能只在有限的时间内可用。如果失败，则无法恢复上传，并且按照第3.5.4.8.3.1节中的过程，需要重新上传完整的文件。使用以下操作：

Get upload info: A client that intends to resume the upload of an interrupted File Transfer shall fetch the upload information of the file by a HTTP GET request to the content server including the TID related to the initial upload or former resume upload (see section 3.5.4.8.3.1).
获取上传信息：意图恢复中断文件传输的上传的客户端将通过到内容服务器的HTTP GET请求获取文件的上载信息，包括与初始上传或前恢复上传相关的TID（参见第3.5.4.8.3.1节）。
GET <FT HTTP CS URI>?tid=<tid_value>&get_upload_info HTTP/1.1
The server sends back the upload information in the following XML structure describing the file content without optional thumbnail including the stored byte range within a file-range tag and the direct upload URI.
服务器以描述文件内容的以下XML结构发回上传信息，没有可选缩略图，包括文件范围标签和直接上传URI中存储的字节范围。
```
<?xml version="1.0" encoding="UTF-8"?>
<file-resume-info xmlns="urn:gsma:params:xml:ns:rcs:rcs:fthttpresume">
 <file-range start="[start-offset in bytes]" end="[end-offset in bytes]" / >
 <data url="[HTTP upload URL for the file]"/>
</file-resume-info>
```
Table 40: File transfer via HTTP upload information content / 表40：通过HTTP上传信息内容进行文件传输
Complying with following schema:
遵循以下模式：
```
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:gsma:params:xml:ns:rcs:rcs:fthttpresume" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:gsma:params:xml:ns:rcs:rcs:fthttpresume" elementFormDefault="qualified" attributeFormDefault="unqualified">
 <xs:element name="file-resume-info">
   <xs:complexType>
     <xs:sequence>
       <xs:element name="file-range">
         <xs:complexType>
           <xs:attribute name="start" type="xs:integer" use="required" />
           <xs:attribute name="end" type="xs:integer" use="required" />
           <xs:anyAttribute namespace="##other" processContents="lax"/>
         </xs:complexType>
       </xs:element>
       <xs:element name="data">
         <xs:complexType>
           <xs:attribute name="url" type="xs:anyURI" use="required"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
         </xs:complexType>
       </xs:element>
       <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>
</xs:schema>
```
Table 41: File transfer via HTTP upload information schema / 表41：通过HTTP上传信息模式进行文件传输
In case of a successful HTTP response by the server, e.g. HTTP 200, including an XML description of the file, the following procedure applies depending on the content of the XML description:
在服务器成功的HTTP响应的情况下，例如 HTTP 200，包括文件的XML描述，根据XML描述的内容，应用以下过程：
- If it includes file-resume-info for the uploaded file content with file range which matches the original file size, the file has been uploaded successfully.
  如果文件包含与原始文件大小匹配的文件范围的上传文件内容的文件恢复信息，则说明文件已成功上传。
- If it includes file-resume-info of the uploaded file content but with file range below the file size, the remaining file content needs to be uploaded using step 2.
  如果它包括上传的文件内容的文件恢复信息，但文件范围低于文件大小，则需要使用步骤2上传剩余的文件内容。
- If it does not include the file-resume-info of the file content, the full upload needs to be started from beginning using the HTTP POST request as described section 3.5.4.8.3.1.
  如果它不包括文件内容的file-resume-info，则需要从开始使用HTTP POST请求开始完全上载，如第3.5.4.8.3.1节所述。
NOTE: The file-range refers to the part of the file that has been uploaded prior to the resume upload.
注意：文件范围是指在恢复上传之前已上载的文件部分。

A server shall send back an HTTP error response if resume upload cannot be performed (e.g. because the partial files are no longer available) according to [RFC2616], e.g. HTTP 404 or 410. An HTTP response that does not contain an XML description of the file or an XML structure that does not include a range field, shall indicate to the client that a resume of the upload of the file is not possible and that therefore a full upload needs to be done again.
如果根据[RFC2616]不能执行恢复上传（例如，因为部分文件不再可用），服务器将发回HTTP错误响应，例如。 HTTP 404或410.不包含文件的XML描述或不包含范围字段的XML结构的HTTP响应应向客户端指示文件的上载的恢复是不可能的，因此需要重新进行完整上传。
Resume upload: In case the client wants to resume the upload of the file content it generates an HTTP PUT request to the upload URL that was included in the XML description provided by the content server in operation 1. In this request it shall provide the remaining bytes started from the already uploaded byte position that was included in the received XML description. To indicate the byte range that is included in the HTTP PUT request a HTTP Content-Range header as defined in [RFC2616] is added to the request:
恢复上传：如果客户端希望恢复文件内容的上传，则它将向操作1中由内容服务器提供的XML描述中包括的上传URL生成HTTP PUT请求。在该请求中，它将提供剩余的字节从包括在接收的XML描述中的已经上传的字节位置开始。为了指示包含在HTTP PUT请求中的字节范围，将向请求中添加[RFC2616]中定义的HTTP Content-Range标头：
```
PUT http://<file_upload_uri> HTTP/1.1
Content-Type: [mime type depending on the file; e.g. image/jpeg]
Content-Length: <remaining_upload_size>
Content-Range: bytes <first-byte-pos> - <last-byte-pos> / <file_size>
Authorization: Digest ...

<file content>
```
Table 42: File transfer via HTTP upload information content / 表42：通过HTTP上传信息内容进行文件传输
When the server receives the partial file, it shall append the data according to the Content-Range header. In case the upload is successful, a HTTP 200 OK response without body is returned.
当服务器接收到部分文件时，它将根据Content-Range头部附加数据。如果上传成功，则返回没有正文的HTTP 200 OK响应。
The client has to ensure that the file content related to the TID has not been changed between the initial HTTP POST request and the resume upload operation.
客户端必须确保与TID相关的文件内容在初始HTTP POST请求和恢复上传操作之间没有被改变。

NOTE: This HTTP PUT can fail, e.g. due to another loss of network coverage. In that case, the operations 1 and 2 may be repeated with the same TID. In that case, the file-range tag indicates the sum of all the data uploaded in the uploaded resumes that have taken place so far.
注意：此HTTP PUT可能会失败，例如。由于网络覆盖的另一损失。在这种情况下，可以用相同的TID重复操作1和2。在这种情况下，文件范围标签指示上传到已经发生的简历中的所有数据的总和。
Get download info: To get the XML description of the complete file to be sent to the file receiver according to 3.5.4.8.3.1, the client sends the following request to the content server:
获取下载信息：要获得要根据3.5.4.8.3.1发送到文件接收器的完整文件的XML描述，客户端向内容服务器发送以下请求：
GET <FT HTTP CS URI>?tid=<tid_value>&get_download_info HTTP/1.1
The server sends back a successful HTTP response including the XML description back if the file has been uploaded successfully. In that case the XML includes the file info for the thumbnail (if provided) and the file (as defined in Table 37). Otherwise an HTTP error response will be returned.
如果文件已成功上传，服务器将返回包含XML描述的成功HTTP响应。在这种情况下，XML包括缩略图（如果提供）和文件（如表37中定义的）的文件信息。否则将返回HTTP错误响应。

NOTE: Like for the initial HTTP POST in section 3.5.4.8.3.1 authentication may be requested for other HTTP requests used in this section. In that case, the client shall sent it a second time carrying the authentication header field in line with the challenge received in the HTTP 401 AUTHENTICATION REQUIRED response to the first request. All additional HTTP requests towards the content server shall use the HTTP digest authentication as defined for regular file upload. In case HTTP over TLS is used, HTTP basic authentication can be used instead.
注意：像第3.5.4.8.3.1节中的初始HTTP POST一样，可以为本节中使用的其他HTTP请求请求认证。在这种情况下，客户端将第二次发送它携带与在对第一请求的HTTP 401 AUTHENTICATION REQUIRED响应中接收的询问一致的认证报头字段。到内容服务器的所有其他HTTP请求都应使用为常规文件上传定义的HTTP摘要认证。在使用HTTP over TLS的情况下，可以使用HTTP基本认证。

The whole procedure (including the initial upload is summarized in following figures:
整个过程（包括初始上传）总结如下图：

Figure 56: File transfer via HTTP: Resume upload / 图56：通过HTTP进行文件传输：继续上传

In case the resume is not possible (anymore), the flow shall be as follows:
如果恢复不可能（以后也不再可能），流程应如下：

Figure 57: File transfer via HTTP: Resume upload not possible / 图57：通过HTTP进行文件传输：无法继续上传

3.5.4.8.3.2 Receiver procedures / 接收程序

When the receiver gets a chat message as described in the previous section, the RCS client shall:
当接收方获得如上一节所述的聊天消息时，RCS客户端应当：

The user shall not be aware a different procedure has been used to carry the file, therefore and, if present, the RCS client shall download (HTTPS GET) the thumbnail and display/notify of the incoming file transfer.
用户不应该知道已经使用了不同的过程来携带文件，因此，如果存在，RCS客户端将下载（HTTPS GET）缩略图并显示/通知传入的文件传输。
If the user accepts, the file shall be downloaded (HTTPS GET) showing the progress of the download as for a file transfer performed for MSRP. If the HTTP content server is working adequately, one of the following three responses shall be returned to the client:
如果用户接受，应该下载文件（HTTPS GET），显示对于MSRP执行的文件传输的下载进度。如果HTTP内容服务器工作正常，以下三个响应之一应返回给客户端：
- HTTP 200 OK: Meaning the file is downloaded The client shall handle the file then according to the file-disposition attribute if included in the File transfer via HTTP message body content (see Table 38 and section 3.5.4.8.3.1).
  HTTP 200 OK：意味着文件被下载客户端将处理文件，然后根据文件配置属性（如果包括在通过HTTP消息体内容的文件传输中）（见表38和第3.5.4.8.3.1节）。
- A HTTP 503 INTERNAL SERVER ERROR with a Retry-After header: In this case the client shall retry, the recommended value to retry will be specified in the “Retry-After” header. Please note that this response is provided by the server when the sender is still uploading the file to prevent the race condition.
  具有Retry-After标头的HTTP 503内部服务器错误：在这种情况下，客户端将重试，将在“重试后”标头中指定建议的重试值。请注意，当发件人仍在上传文件以防止竞态条件时，服务器会提供此响应。
- Any other error: The client shall retry up to a maximum of 3 times. In case the file was partially downloaded already, a partial HTTP GET request as defined in [RFC2616] may be used to obtain the remaining part of the file.
  任何其他错误：客户端最多重试3次。如果文件已经部分下载，则可以使用[RFC2616]中定义的部分HTTP GET请求来获取文件的剩余部分。
Regarding the display notification associated to this chat message, it shall only be sent when the file has been successfully downloaded to indicate the sender that the file has been effectively downloaded by the user.
关于与该聊天消息相关联的显示通知，仅当文件已经被成功下载以指示发送者该文件已被用户有效下载时，才会发送该消息。

Finally note that if validity of the file to be downloaded indicates that it may no longer be available on the server, the client shall inform the user of the circumstance when trying to download the file. The detailed UX is left intentionally outside the scope of this specification and it is up to the RCS client implementation.
最后注意，如果要下载的文件的有效性指示它可能不再在服务器上可用，客户端将通知用户尝试下载文件的情况。详细的UX故意超出本规范的范围，这取决于RCS客户端实现。

Figure 58: File transfer via HTTP: Receiver procedures / 图58：通过HTTP进行文件传输：接收方过程

# 3.5.4.8.3.2.1 File transfer auto-accept / 文件传输自动接受

Consistently with Annex A sections A.1.5 and A.2.6, if the parameter FT AUT ACCEPT is set to 1 and the indicate file size is smaller than the size configured in the FT WARN SIZE configuration parameter, the receiving client shall not only download automatically the thumbnail but also the file content.
与附件A A.1.5和A.2.6节一致，如果参数FT AUT ACCEPT设置为1并且指示文件大小小于FT WARN SIZE配置参数中配置的大小，则接收客户端不仅应自动下载缩略图，还有文件内容。

3.5.4.8.4 HTTP Content server addressing / HTTP内容服务器寻址

In order to enable the traceability of the HTTP transactions among operators, the HTTP content server FQDN shall follow the format presented below:
为了实现运营商之间的HTTP事务的可追溯性，HTTP内容服务器FQDN应遵循以下所示的格式：

ftcontentserver.rcs.mnc<MNC>.mcc<MNC>.pub.3gppnetwork.org

Table 43: HTTP content server FQDN / 表43：HTTP内容服务器FQDN

3.5.4.8.5 Security considerations / 安全注意事项

In order to guarantee the integrity and security of the solution for file transfer via HTTP the following three principles shall be taking into account:
为了保证通过HTTP进行文件传输的解决方案的完整性和安全性，应考虑以下三个原则：

The security of the solution relies on the security of the chat messages. Therefore, encryption of the media associated to Chat (1-to-1/Group Chat) media is recommended.
解决方案的安全性取决于聊天消息的安全性。因此，建议对与聊天（1对1 /群聊）媒体相关联的媒体进行加密。
All HTTP transactions shall be secured using HTTPS.
所有HTTP事务都应使用HTTPS进行安全保护。
To secure interoperability between Service Providers and to reduce complexity on the RCS device/client, the HTTP configuration server shall make use of public root certificates issued by a recognised CA. That is the root certificates are similar to those used by standard webservers which are widely recognised by browsers and web-runtime implementations both in PCs and devices.
为了确保服务提供商之间的互操作性并降低RCS设备/客户端上的复杂性，HTTP配置服务器应利用由公认CA发布的公共根证书。也就是说，根证书类似于标准网络服务器使用的那些，这些网络服务器被PC和设备中的浏览器和网络运行时实现广泛认可。

3.5.4.8.7 File Transfer Fallback / 文件传输回退

When the configuration parameter FT HTTP FALLBACK defined in section A.1.5 is set to 1, an RCS client shall use the following procedure to send files and multimedia content to a contact that does not support any of the enabled File Transfer mechanisms (including a non RCS contact):
当部分A.1.5中定义的配置参数FT HTTP FALLBACK设置为1时，RCS客户端将使用以下过程向不支持任何启用的文件传输机制的联系人发送文件和多媒体内容（包括非 RCS联系人）：

The RCS client shall upload the content to the HTTP Content Server as defined in steps 2 to 4 of section 3.5.4.8.3.1. A thumbnail shall not be provided in this case.
RCS客户端应将内容上传到HTTP内容服务器，如第3.5.4.8.3.1节的步骤2到4所定义。在这种情况下不应提供缩略图。
The RCS client shall extract the link and optionally the validity from the obtained XML body.
RCS客户端将从获取的XML主体中提取链接和可选的有效性。
The RCS client shall compose a regular text message including the link and optionally the validity.
RCS客户端将编写包括链接和可选的有效性的常规文本消息。

NOTE: The exact content of the message is out of scope of this specification.
注意：消息的确切内容超出了本规范的范围。
The RCS client shall send this text message to the contact using its standard technology for sending text messages to such contacts (e.g. SMS).
RCS客户端应使用其向这些联系人（例如SMS）发送文本消息的标准技术向联系人发送该文本消息。

3.5.4.8.7 HTTP State Management / HTTP状态管理

The client should support for the HTTP procedures for File Transfer via HTTP state management defined in [RFC6265]. This includes all HTTP requests and responses between the client and content servers as part of the File Transfer procedure defined in section 3.5.4.8.3. This allows a content server to return in HTTP responses a Set-Cookie header. The client should apply the parsing and storage procedures of the Set-Cookie header as defined [RFC6265]. It should send the cookie header in HTTP requests to content servers respecting the cookie attributes provided by the server in the Set-Cookie header in accordance with [RFC6265].
客户端应该支持[RFC6265]中定义的HTTP状态管理的文件传输的HTTP过程。这包括客户端和内容服务器之间的所有HTTP请求和响应，作为第3.5.4.8.3节中定义的文件传输过程的一部分。这允许内容服务器在HTTP响应中返回Set-Cookie头。客户端应该应用定义的Set-Cookie头的解析和存储过程[RFC6265]。它应该根据[RFC6265]将HTTP请求中的cookie头发送到遵守服务器在Set-Cookie头中提供的cookie属性的内容服务器。

With this the content server is able to make use of all the functions of HTTP state management.
这样，内容服务器能够利用HTTP状态管理的所有功能。

NOTE: It is left to service provider policies to ensure that response does not include the cookie towards legacy clients.
注意：HTTP状态管理问题留给服务提供商策略，以确保响应不包括针对旧客户端的cookie。

3.5.4.9 Handling of specific content / 处理具体内容

3.5.4.9.1 Personal Card format / 个人卡格式

Current implementations of the vCard standard by different device manufacturers leads today to data loss of certain contact information, when this information is exchanged among devices or synced with network address books. An RCS compliant device shall support receiving at a minimum, vCard 2.1 [vCard21] and vCard 3.0 formats [RFC2425], [RFC2426] and may support also the Personal Contact Card (PCC) format [CAB_TS].
当前，不同设备制造商的vCard标准的实施导致当某些联系人信息在设备之间交换或与网络地址簿同步时，某些联系人信息的数据丢失。 RCS兼容设备应当支持至少接收vCard 2.1 [vCard21]和vCard 3.0格式[RFC2425]，[RFC2426]，并且还可以支持个人联系卡（PCC）格式[CAB_TS]。

The following fields are considered key fields. No data of these fields should be lost when contact information is exchanged by any means (peer to peer contact sent, uploaded, synchronised, etc.):
以下字段被视为关键字段。当通过任何方式（发送，上传，同步等的对等联系人）交换联系信息时，不应丢失这些字段的数据：

Name / 姓名
Telephone numbers / 电话号码
Email addresses / 电子邮件地址
Address information / 地址信息
Personal information / 个人信息

The Minimum subtypes that should be supported are defined in the PCC definition in [CAB_TS]:
应支持的最小子类型在[CAB_TS]中的PCC定义中定义：

Name: Composed names (such as “Jean-Baptiste”) shall be supported properly.
姓名：应正确支持姓名组合（如“Jean-Baptiste”）。
Personal Information: / 个人信息：
- Nickname / 昵称
- Photo / 照片
- Birthdate / 出生日期
- Comment / 注解
Telephone number: At least the following subtypes of telephone number shall be supported:
电话号码：至少应支持以下电话号码子类型：
- Land home / 家用固定电话
- Land work / 工作固定电话
- Land other / 其他固定电话
- Mobile home / 家用手机
- Mobile work / 工作手机
- Mobile other / 其他手机
- Fax work / 工作传真
- Fax other / 其他传真
- Beeper / BB机
- Other / 其他
Email addresses: The following subtypes shall be supported:
电子邮件地址：应支持以下子类型：
- Email work 1 / 工作电子邮件1
- Email work 2 / 工作电子邮件2
- Email home 1 / 家用电子邮件1
- Email home 2 / 家用电子邮件2
- Other / 其他
Address information / 地址信息
- Address / 地址
- Geographic Position / 地理位置
- Time zone / 时区

Sending and receiving a contact card via File Transfer is technically the same as sending any other file.
通过文件传输发送和接收联系人卡片在技术上与发送任何其他文件相同。

If the format for pushing a contact card file is vCard 2.1 or 3.0 formats, the MIME (Multipurpose Internet Mail Extensions) type that shall be used for the file transfer is “text/vcard”.
如果推送联系人卡片文件的格式为vCard 2.1或3.0格式，则用于文件传输的MIME（多用途Internet邮件扩展）类型为“text/vcard”。

If the format for pushing the contact card is CAB (Converged Address Book) 1.0 PCC XML format, then the CAB PCC MIME type “application/vnd.oma.cab-pcc+xml” shall be used.
如果推送联系人卡的格式是CAB（融合地址簿）1.0 PCC XML格式，则应使用CAB PCC MIME类型“application/vnd.oma.cab-pcc+xml”。

On the receiving side, after the receiving RCS user accepts the contact card file delivered through File Transfer, the receiving RCS client shall apply the mapping of the RCS supported fields between the received format (CAB PCC XML for example) and the used format of the local address book database[33].
在接收侧，在接收RCS用户接受通过文件传送递送的联系人卡文件之后，RCS接收客户端应当在接收格式（例如，CAB PCC XML）和所使用的本地地址簿数据库格式之间应用RCS支持字段的映射[33]。

vCard 3.0 format is recommended in RCS.
在RCS中推荐使用vCard 3.0格式。

If the receiving side does not support the offered format identified in the a=file-selector attribute of the SIP INVITE SDP, it should reject the File Transfer invitation with an error response indicating it does not support the content-type, which then causes the sending side to initiate a second File Transfer, this time sending the contact card in a different format.
如果接收侧不支持在SIP INVITE SDP的a=file-selector属性中标识的所提供的格式，则它应当拒绝具有指示它不支持内容类型的错误响应的文件传送邀请，然后该内容类型导致发送方发起第二次文件传输，这次以不同的格式发送联系人卡片。

[33] If the conversion between PCC and vCard is required, please see [CAB_TS] section 5.4.3 “Format Adaptation”.
[33] 如果需要在PCC和vCard之间进行转换，请参见[CAB_TS]第5.4.3节“格式适配”。

3.5.4.9.2 Audio Message / 音频消息

The handling of audio messages is described in section 3.11.4.
音频消息的处理在3.11.4节中描述。

3.5.5 NNI and IOT considerations / NNI和IOT考虑

In addition to what is defined in Section 2.12, the mapping of the appropriate File Transfer feature tags is done by the Messaging Server, as per Appendix G in [RCS-CPM- CONVFUNC-ENDORS] when it is determined that the remote network requires such interworking.
除了在2.12节中定义的内容之外，当确定远程网络需要这样的情况时，消息服务器根据[RCS-CPM-CONVFUNC-ENDORS]中的附录G来完成适当的文件传输特征标签的映射互通。

3.5.6 Implementation guidelines and examples / 实施指南和示例

From the UX perspective there are five possible entry points to this service:
从UX角度来看，有五个可能的切入点：

Address book/Call-log: A file transfer can be initiated with any registered contact providing the correct capabilities are in place. This is contact oriented initiation. Following the address book interaction, the list of available files is displayed allowing the user to select one or more files to share. Once the file transfer commences, the progress can be checked in the standard notification area.
地址簿/呼叫日志：只要具备正确的能力，就可以与任何已注册的联系人进行文件传输。这是接触导向的引发。在地址簿交互之后，显示可用文件的列表，允许用户选择一个或多个要共享的文件。文件传输开始后，可以在标准通知区域中检查进度。

Figure 59: Reference UX for accessing file share from address book/call-log / 图59：用于从通讯簿/呼叫日志访问文件共享的参考UX
Media gallery/File browser: The user can browse, select a file (or multiple files) and then share these with one or more RCS users. This is task contact oriented initiation. Only RCS capable users shall be displayed as candidate recipients of the file.
媒体库/文件浏览器：用户可以浏览，选择一个文件（或多个文件），然后与一个或多个RCS用户共享这些文件。这是任务接触导向的启动。只有具有RCS能力的用户才能显示为文件的候选收件人。

Figure 60: Reference UX for accessing file share from media gallery or file browser / 图60：用于从媒体库或文件浏览器访问文件共享的参考UX
In the previous figure, once File Transfer is selected, the user will be presented with the complete list of RCS contacts (including contacts which are currently not registered).
在上图中，一旦选择了文件传输，将向用户显示RCS联系人（包括当前未注册的联系人）的完整列表。
In this case, a SIP OPTIONS or Presence exchange is triggered once a contact is selected from the list.
在这种情况下，一旦从列表中选择联系人，就会触发SIP OPTIONS或Presence交换。
Camera application: The experience is similar to the media gallery/file browser experience with the difference being that the user is able to select only the last picture or video (and, in some cases, a picture or video from the camera gallery) to be shared.
相机应用程序：体验类似于媒体库/文件浏览器体验，区别在于用户能够仅选择最后的图片或视频（以及在某些情况下，从相机图库中选择图片或视频）进行共享。
Chat window: From the Chat window a file can be shared using the relevant button/icon. The experience is identical to the address book/call-log. The user is redirected to the media gallery or file explorer where the user can choose a file which, is then shared with the conversation partner(s).
聊天窗口：从聊天窗口可以使用相关按钮/图标共享文件。体验与地址簿/呼叫日志相同。用户被重定向到媒体库或文件浏览器，其中用户可以选择文件，然后与会话伙伴共享该文件。

Figure 61: Reference UX for accessing file share from a Chat window / 图61：用于从聊天窗口访问文件共享的参考UX
Call screen (Image Share): a picture can be shared either from the camera (front or back) or by choosing a file from the media gallery. Please note this case has been covered in detail in section 3.6.6.1.2.
呼叫屏幕（图像共享）：可以从相机（前面或后面）或从媒体库中选择一个文件共享图片。请注意，这个案例在3.6.6.1.2节已经详细说明。

3.5.6.1 Handling of specific content / 处理具体内容

3.5.6.1.1 Personal Card handling / 个人名片处理

The personal and business cards of the RCS user may be stored in a way that is compliant to the CAB 1.0 PCC data in the RCS client which enables the RCS user to create and populate any number views on the personal and/or business contact information as needed. A client may tag these with their dedicated purposes (professional, friends, etc.).
RCS用户的个人和名片可以以符合RCS客户端中的CAB 1.0 PCC数据的方式存储，其使得RCS用户能够按照需要创建和填充关于个人和/或商业联系人信息的任何数字视图。客户可以用他们的专用目的（专业，朋友等）标记这些。

A Personal Card is, from a technical perspective, the same as any other contact card. This functionality only requires certain user experience changes. In particular:
从技术角度来看，个人名片与任何其他联系人名片相同。此功能仅需要更改特定的用户体验。尤其是：

Visibility as an option in the address book menu.
作为地址簿菜单中的选项的可见性。
A special name/mark in the address book to easily distinguish it from the rest of the contacts.
地址簿中的特殊名称/标记，以便轻松地将其与其余联系人区分开。

It is recommended to support at least three Personal Cards. In particular:
建议至少支持三张个人名片。尤其是：

Business Card: For professional use.
商务名片：专业使用。
Two more Personal Cards to allow social uses (e.g., a contact card to be exchanged with closest friends for having fun, including frequently updated fields such as a personal picture) and an additional one to allow having a stable personal profile for non-professional uses.
两张个人名片，一张用于社交用途（例如，联络名片与亲近的朋友交换以互娱，包括经常更新的字段，如个人图片）；另外一张允许具有稳定的个人资料，用于非专业用途。

3.5.6.1.2 Personal Contact Card entry points / 个人联系人名片入口点

Sending a contact card / 发送联系人名片

The user selects any of the contacts in the address book. Entry points for sending a contact could be:
用户选择地址簿中的任何联系人。发送联系人的入口点可以是：

Chat / 聊天
Address book / 地址簿
Call log / 通话记录

Before sending a contact card, the user should have the option to preview the information. The possibility of editing the information should be available so that filtering the contact information to be sent is also allowed. Once the contact information is confirmed, the contact card is sent over File Transfer.
在发送联系人名片之前，用户应该可以选择预览信息。应允许编辑预览信息，以允许过滤要发送的联系人信息。一旦确认联系人信息，通过文件传输发送联系人名片。

Receiving a contact card / 接收联系人名片

When a new contact card is received, the user is prompted to accept the file. Once accepted, two options are given:
当接收到新的联系人名片时，提示用户接受该文件。一旦被接受，给出两个选项：

Save contact card / 保存联系人名片
View contact card / 查看联系人名片

If ‘Save Contact information’ is chosen proper options will be given depending on whether the contact received already exists or not in the receiver’s address book. If it exists the existing contact information will be implemented with the additional information received.
如果选择“保存联系人信息”，将根据收件人的通讯录中是否已存在联系人来给出适当的选项。如果存在，将使用收到的附加信息实施现有联系信息。

3.5.6.1.3 Audio Messages / 音频消息

The entry points for audio messages are described in section 3.11.6.
音频消息的入口点在3.11.6节中描述。