3.6 Content sharing / 内容共享
3.6.1 Feature description / 功能描述
3.6.1.1 In-Call Image Share and Video Share / 即时图像共享和视频共享
Content sharing provides the capability to share videos and pictures in near real-time. This functionality can be used in connection to a voice. When the receiving user has multiple devices the content sharing requests are sent to all those devices. Therefore, the user can decide to accept the shared content on a different device than the one they are using for the voice call if that device has better display capabilities for instance.
内容共享提供近乎实时地共享视频和图片的能力。 此功能可用于连接语音。 当接收用户具有多个设备时，内容共享请求被发送到所有这些设备。 因此，举例来说，如果该设备具有更好的显示能力，用户可以决定在与用于语音呼叫的设备不同的设备上接受共享内容。
There can be different sources for the shared videos and pictures:
共享视频和图片可能有不同的来源：
- The front camera (“me”)
前置摄像头（“我”） - The rear camera (“what I see”)
后置摄像头（“我看到的”） - A file (“video streaming” or “sending of a stored image”)
文件（“视频流”或“发送存储的图像”）
A Service Provider configurable parameter allows the Service Provider to set the maximum duration of a Video Share session (see VS MAX DURATION in section A.1.6) and the max size of a file transferred during Image Share (see IS MAX SIZE in section A.1.6).
服务提供商可配置参数允许服务提供商设置视频共享会话的最大持续时间（请参阅第A.1.6节中的VS MAX DURATION）和在图像共享期间传输的文件的最大大小（参见第A1.6节中的IS MAX SIZE）。
From the user experience perspective and assuming that the duration and size limitations are in place (i.e. the values are non-zero):
从用户体验的角度来看，假设持续时间和大小限制已设置（即值非零）：
- When performing a video share, if the session duration (send or receive) is approaching the VS MAX DURATION, a warning notification could be displayed for the user.
当执行视频共享时，如果会话持续时间（发送或接收）接近VS MAX DURATION，则可以为用户显示警告通知。 - When performing a video share, if the session duration (send or receive) is longer than the VS MAX DURATION, a warning message will be displayed and the video share session will be cancelled (that is at protocol level, the SIP BYE request will be sent to the other end).
当执行视频共享时，如果会话持续时间（发送或接收）长于VS MAX DURATION，将显示警告消息，并且将取消视频共享会话（此操作位于协议级别，SIP BYE请求将被发送到另一端）。 - If the picture size in an image share session is bigger than IS MAX SIZE, a warning message will be displayed when trying to send or receive a picture larger than the mentioned limit and the image share session will be cancelled (that is at protocol level, the SIP INVITE request will never be sent or an automatic rejection response will be sent to the other end depending on the scenario).
如果图像共享会话中的图片大小大于IS MAX SIZE，则当尝试发送或接收大于上述限制的图片时将显示警告消息，并且图像共享会话将被取消（此操作位于协议级别， 将不会发送SIP INVITE请求，或者根据场景将自动拒绝响应发送到另一端）。
The in-call Video Share and Image Share services are linked to the call. Therefore, they are also automatically terminated when the call ends.
呼叫中的视频共享和图像共享服务将链接到呼叫。 因此，当呼叫结束时，它们也自动终止。
All services are delivered as one to one only and there is no multiparty sharing provided. For the content sharing during a call, the user should be able to recognise which content sharing services (e.g. Video and Share or Image Share) are available to use with their conversation partner. Therefore, both ends need to be updated on the respective capabilities to avoid showing a service as available when this is no longer the case. This is achieved through the capability exchange described in section 2.6.
所有服务都是一对一交付的，没有提供多方共享。 对于在呼叫期间的内容共享，用户应该能够识别哪些内容共享服务（例如，视频和共享或图像共享）可用于他们的对话伙伴。 因此，两端需要对相应的能力进行更新，以避免当不再是这种情况时将服务显示为可用。 这是通过2.6节中描述的能力交换来实现的。
Video Share and Image Share are unidirectional services and do not need a dedicated audio path. It is possible to establish simultaneous Image and/or Video Share sessions in each direction. For example when referring to bidirectional Video Share, this means that once User A is sharing video with User B, User B can also start to share video with User A simultaneously, provided the right coverage conditions are in place. In this case, each Video Share session is independent and should be handled separately. When a user’s coverage conditions change while such bi-directional sharing is active, the device that changed coverage shall terminate the sharing session that it initiated. The same example would also apply to Image Share or to a combination of Video Share in one direction and Image Share in the other.
视频共享和图像共享是单向服务，并且不需要专用的音频路径。 可以在每个方向上建立同时的图像和/或视频共享会话。 例如，当提及双向视频共享时，这意味着一旦用户A与用户B共享视频，用户B也可以开始与用户A同时共享视频，只要适当的覆盖条件就位。 在这种情况下，每个视频共享会话是独立的，应该单独处理。 当用户的覆盖条件改变而这种双向共享活动时，改变覆盖的设备将终止其发起的共享会话。 同样的示例也适用于图像共享或一个方向上的视频共享和另一个方向上的图像共享的组合。
3.6.1.2 In-Call Shared Map and Shared Sketch / 通话共享地图和共享草图
This provides the capability to share maps and drawing canvas in near real-time. This functionality can be used during a voice call.
这提供了几乎实时地共享地图和绘制画布的能力。 此功能可以在语音通话期间使用。
3.6.1.2.1 Shared Map / 共享地图
The Shared Map application lets two users draw, share markers and view each other’s position on a “shared” map. The service description is provided in section 1.1 of [PRD- RCC.20].
共享地图应用程序允许两个用户在“共享”地图上绘制，共享标记和查看彼此的位置。 服务描述在[PRD-RCC.20]的第1.1节中提供。
3.6.1.2.2 Shared Sketch
The Shared Sketch application lets two users, draw, add background images, change background colour on a “shared” canvas. The service description is provided in section 1.1 of [PRD-RCC.20].
共享草图应用程序允许两个用户绘制，添加背景图片，更改“共享”画布上的背景颜色。 服务描述在[PRD-RCC.20]的第1.1节中提供。
3.6.1.3 Call Composer and Post-call service / 呼叫编辑和呼叫后服务
This provides the capability to share multi-media content ahead of the call to provide context to the called party when the call is set up and to share a note (reason) or a voice message after an unanswered call.
这提供了在呼叫之前共享多媒体内容以在呼叫建立时向被叫方提供上下文以及在未应答呼叫之后共享笔记（原因）或语音消息的能力。
3.6.1.3.1 Call composer / 呼叫编辑
For sharing pre-call rich content related to a voice call, the descriptions in section 1.1 of [PRD-RCC.20] shall be taken into consideration.
为了共享与语音呼叫相关的呼叫前富内容，应考虑[PRD-RCC.20]第1.1节中的描述。
3.6.1.3.2 Post-Call service / 后呼叫服务
For sharing a note (reason) or a voice message after an unanswered call, the descriptions in section 1.1 of [PRD-RCC.20] shall be taken into consideration.
为了在未应答呼叫之后共享笔记（原因）或语音消息，应考虑[PRD-RCC.20]第1.1节中的描述。
3.6.1.4 Use Cases / 用例
3.6.1.4.1 Share Video during a voice call / 在语音通话期间分享视频
Figure 62: Sharing video during a voice call / 图62：在语音通话期间共享视频
Figure 62 illustrates the behaviour when the voice call is set up in the CS domain. Apart from the voice call itself, the behaviour would be identical though if one or both parties used the PS domain for the voice call as specified in section 3.8 since the sharing service functions independently of the voice call.
图62示出了当在CS域中建立语音呼叫时的行为。 除了语音呼叫本身之外，尽管如果一方或双方使用PS域用于语音呼叫，如在第3.8节中所指定的，但是行为将是相同的，因为共享服务独立于语音呼叫而起作用。
NOTE: When both of the devices involved in the sharing are on a high bandwidth access, for example LTE, the perceived video quality will be higher.
注意：当共享中涉及的两个设备都处于高带宽访问（例如LTE）时，感知的视频质量将更高。
3.6.1.4.2 Sharing video during a call in the multidevice environment / 在多设备环境中的呼叫期间共享视频
User A has a mobile device and a broadband access device (RCS PC client). User B has a mobile device.
用户A具有移动设备和宽带接入设备（RCS PC客户端）。 用户B具有移动设备。
- User B has travelled to Hong Kong and is visiting the Victoria’s peak. The view from top of the peak is astonishing and they would like to share the experience with their friend User A.
用户B已前往香港，正游览维多利亚山的顶峰。顶峰的风景令人震撼，他们想与他们的朋友用户A分享这一体验。 - User B makes a call to User A.
用户B呼叫用户A. - User A answers on the mobile.
用户A在手机上应答。 - User B tells User A about the view they are viewing. To prove this User B decides to share a video with User A.
用户B告诉用户A他们正在观看的风景。 为了证明自己，用户B决定与用户A共享视频。 - User B sees from the call menu that they can share video with User A. User B sends the request to share video, for example, by clicking the Video Share icon.
用户B从呼叫菜单看到他们可以与用户A共享视频。用户B发送共享视频的请求，例如，通过点击视频共享图标。 - The request is sent to both User A’s mobile and PC; both mobile and PC will alert.
该请求被发送到用户A的移动设备和PC; 移动设备和PC都会发出提醒。 - As User A is sitting in front of their PC he/she decides to take the video to the PC for example, by clicking accept button on the PC client.
举例来说，当用户A正坐在他们的PC的前面时，他/她决定通过点击PC客户端上的接受按钮来使用PC接收视频。 - User A’s mobile will then stop alerting.
用户A的移动设备将停止提醒。 - User A will now see the beautiful scenery shared by User B in their PC while still having the voice call on the mobile.
用户A现在将在他们的PC中看到用户B共享的美丽风景，同时仍然在移动设备上进行语音呼叫。
NOTE: This was illustrated previously in Figure 62. The behaviour would be similar when sharing an image.
注意：这在前面的图62中说明。共享图像时的行为类似。
3.6.1.4.3 Share an Image during a call / 在通话期间共享图像
Figure 63: Sharing an image during a call / 图63：在通话期间共享图像
Figure 63 illustrates the behaviour when the voice call is set up in the CS domain. Apart from the voice call itself, the behaviour would be identical though if one or both parties used the PS domain for the voice call as specified in section 3.8 since the sharing service functions independently of the voice call.
图63示出了当在CS域中建立语音呼叫时的行为。 除了语音呼叫本身之外，尽管如果一方或双方使用PS域用于语音呼叫，如在第3.8节中所指定的，但是行为将是相同的，因为共享服务独立于语音呼叫而起作用。
3.6.2 Interaction with other RCS features / 与其他RCS功能的交互
3.6.2.1 Voice Call / 语音通话
The Video Share, Image Share, Shared Map and Shared Sketch services during a voice call (either over CS or as specified in section 3.8) interacts with that voice call since the sharing is automatically terminated when the call is terminated. There is also an interaction with the supplementary services of that voice call.
语音通话期间的视频共享，图像共享，共享地图和共享草图服务（通过CS或3.8节中指定的）与该语音通话交互，因为共享在通话终止时自动终止。 还存在与该语音呼叫的补充服务的交互。
NOTE: This interaction does not apply for the File Transfer and 1-to-1 chat service. The sharing session is independent of that voice call and progresses independently of the voice call continuity.
注意：此交互不适用于文件传输和1对1聊天服务。 共享会话独立于该语音呼叫并且独立于语音呼叫的连续性而发展。
3.6.2.1.1 Multiparty call and In-Call sharing services / 多方通话和通话共享服务
Once a voice call is established between two users, it is possible for one of them to add another party to the call, and consequently, initiate a multiparty call. From RCS services perspective and as presented in section 2.7, the Image Share, Video Share, Shared Map and Shared Sketch services are not available during a multiparty call. Therefore, the terminal should manage the following scenarios:
一旦在两个用户之间建立语音呼叫，则他们中的一个可以向呼叫添加另一方，并且因此发起多方呼叫。 从RCS服务角度来看，如第2.7节所述，在多方呼叫期间，图像共享，视频共享，共享地图和共享草图服务不可用。 因此，终端应该管理以下场景：
- The users were in a voice call without using the Image Share, Video Share, Shared Map or Shared Sketch services: In this case, when switching to a multiparty call the client starting the process has to send a SIP OPTIONS request with a capability update (as described in section 3.6.4.7.2) indicating that the Content Sharing services during a call are no longer available. The on-screen icons/layout should be updated accordingly.
用户在不使用图像共享，视频共享，共享地图或共享草图服务的情况下进行语音呼叫：在这种情况下，当切换到多方呼叫时，启动过程的客户端必须发送具有能力更新的SIP OPTIONS请求 如第3.6.4.7.2节所述），表示呼叫期间的内容共享服务不再可用。 屏幕上的图标/布局应相应更新。 - The users (User A and User B) were in a voice call using Video Share: In this case, switching to a multiparty call means ending the Video Share service. This can either be sender or receiver terminated, depending upon the circumstances, as described in sections 3.6.4.7.4 and 3.6.4.7.5 respectively. In both cases, a capabilities exchange using SIP occurs and, consequently, the client initiating the multiparty call should report that the Content Sharing services/capabilities during a call are no longer available. The on-screen icons/layout should be updated accordingly.
用户（用户A和用户B）使用视频共享进行语音通话：在这种情况下，切换到多方通话意味着结束视频共享服务。 这可以是发送方或接收方终止，取决于具体情况，分别在3.6.4.7.4和3.6.4.7.5中描述。 在这两种情况下，使用SIP的能力交换发生，因此，发起多方呼叫的客户端应该报告呼叫期间的内容共享服务/能力不再可用。 屏幕上的图标/布局应相应更新。 - The users (User A and User B) were in a voice call using Image Share with the transfer not yet completed: In this case, switching to a multiparty call means ending the Image Share service. This either can be sender or receiver terminated, depending upon the circumstances, as described in sections 3.6.4.7.8 and 3.6.4.7.9 respectively. In both cases, a capabilities exchange using SIP OPTIONS occurs and, consequently, the client initiating the multiparty call should report that the Content Sharing services/capabilities during a call are no longer available. The on-screen icons/layout should be updated accordingly.
用户（用户A和用户B）使用图像共享进行语音通话，但传输尚未完成：在这种情况下，切换到多方通话意味着结束图像共享服务。 这可以是发送方或接收方终止，取决于具体情况，分别在3.6.4.7.8和3.6.4.7.9中描述。 在这两种情况下，使用SIP OPTIONS的能力交换发生，因此，发起多方呼叫的客户端应当报告呼叫期间的内容共享服务/能力不再可用。 屏幕上的图标/布局应相应更新。 - The users (User A and User B) were in a voice call using Image Share after the transfer has completed: In this case, switching to a multiparty call means that the picture is no longer shown in the call screen and that the client starting the process has to send a SIP OPTIONS message with a capability update (as described in section 3.6.4.7.2) indicating that the Content Sharing services during a call are no longer available. The on-screen icons/layout should be updated accordingly.
在传输完成后，用户（用户A和用户B）使用图像共享进行语音呼叫：在这种情况下，切换到多方呼叫意味着图片不再显示在呼叫屏幕中，并且客户端启动 进程必须发送具有能力更新（如第3.6.4.7.2节所述）的SIP OPTIONS消息，指示呼叫期间的内容共享服务不再可用。 屏幕上的图标/布局应相应更新。 - The users (User A and User B) were in an active Shared Map session: In this case, switching to a multiparty call means ending the Shared Map session. This can be initiated by either user (user A or user B) depending upon the circumstances. A capabilities exchange using SIP occurs and, consequently, the client initiating the multiparty call should report that the Content Sharing services/capabilities during a call are no longer available.
用户（用户A和用户B）处于活动的共享地图会话中：在这种情况下，切换到多方呼叫意味着结束共享地图会话。 这可以由用户（用户A或用户B）根据情况启动。 使用SIP的能力交换发生，因此，发起多方呼叫的客户端应该报告在呼叫期间内容共享服务/能力不再可用。 - The users (User A and User B) were in an active Shared Sketch session: In this case, switching to a multiparty call means ending the Shared Sketch session. This can be initiated by either user (user A or user B) depending upon the circumstances. A capabilities exchange using SIP occurs and, consequently, the client initiating the multiparty call should report that the Content Sharing services/capabilities during a call are no longer available.
用户（用户A和用户B）处于活动的共享草图会话中：在这种情况下，切换到多方呼叫意味着结束共享草图会话。 这可以由用户（用户A或用户B）根据情况启动。 使用SIP的能力交换发生，因此，发起多方呼叫的客户端应该报告在呼叫期间内容共享服务/能力不再可用。
It should be also noted that from the moment the users enter in a multiparty call, it is not necessary to perform the capability exchange described in section 3.6.4.7.2.
还应注意，从用户进入多方呼叫的那一刻起，没有必要执行在3.6.4.7.2中描述的能力交换。
Finally, if the multiparty call is converted into a standard call (That is it becomes again a 1- to-1 call), this event should be treated as a new call establishment meaning that a capability exchange via OPTIONS needs to take place and, consequently, the relevant on screen icons need to be updated.
最后，如果多方呼叫被转换为标准呼叫（即它再次成为1对1呼叫），则该事件应当被视为新的呼叫建立，意味着需要通过OPTIONS进行能力交换， 因此，需要更新相关的屏幕图标。
3.6.2.1.2 Call on hold and In-Call sharing services / 呼叫保持和呼叫共享服务
Once a voice call is established between two users, it is possible for one of them to put the other party on hold. From RCS services perspective and as presented in section 2.6.3.1, the Image Share, Video Share, Shared Map and Shared Sketch services are not available during a call which is not active, therefore, the terminal needs to manage the following scenarios:
一旦在两个用户之间建立语音呼叫，他们中的一个可以使另一方保持。 从RCS服务的角度来看，如第2.6.3.1节所述，在非活动呼叫期间，图像共享，视频共享，共享映射和共享草图服务不可用，因此终端需要管理以下情况：
- The users were on a voice call without using the Image Share, Video Share, Shared Map or Shared Sketch services: In this case, when putting the call on hold the client starting the process has to send an SIP OPTIONS request with a capability update (as described in section 3.6.4.7.2) indicating that the Content Sharing services during a call are no longer available. The on-screen icons/layout should be updated accordingly.
用户在不使用图像共享，视频共享，共享映射或共享草图服务的情况下进行语音呼叫：在这种情况下，当将呼叫保持时，客户端开始过程必须发送具有能力更新的SIP OPTIONS请求 如第3.6.4.7.2节所述），表示呼叫期间的内容共享服务不再可用。 屏幕上的图标/布局应相应更新。 - The users (User A and User B) were in a voice call using Video Share: In this case, putting the call on hold means ending the Video Share service. This can either be sender or receiver terminated, depending upon the circumstances, as described in sections 3.6.4.7.4 and 3.6.4.7.5 respectively. In both cases, a capabilities exchange using SIP OPTIONS occurs and, consequently, the client putting the call on hold should report that the Content Sharing services/capabilities during a call are no longer available. The on-screen icons/layout should be updated accordingly.
用户（用户A和用户B）使用视频共享进行语音呼叫：在这种情况下，将呼叫置于保持状态意味着结束视频共享服务。 这可以是发送方或接收方终止，取决于具体情况，分别在3.6.4.7.4和3.6.4.7.5中描述。 在这两种情况下，使用SIP OPTIONS的能力交换发生，因此，保持呼叫的客户端应该报告呼叫期间的内容共享服务/能力不再可用。 屏幕上的图标/布局应相应更新。 - The users (User A and User B) were in a voice call using Image Share with the transfer not having completed: In this case, putting the call on hold means ending the Image Share service. This can either be sender or receiver terminated, depending upon the circumstances, as described in sections 3.6.4.7.8 and 3.6.4.7.9 respectively. In both cases, a capabilities exchange using SIP OPTIONS occurs and, consequently, the client putting the call on hold should report that the Content Sharing services/capabilities during a call are no longer available. The on-screen icons/layout should be updated accordingly.
用户（用户A和用户B）使用图像共享进行语音呼叫，传输未完成：在这种情况下，将呼叫置于保持状态表示结束图像共享服务。 这可以是发送方或接收方终止，取决于具体情况，分别在3.6.4.7.8和3.6.4.7.9中描述。 在这两种情况下，使用SIP OPTIONS的能力交换发生，因此，保持呼叫的客户端应该报告呼叫期间的内容共享服务/能力不再可用。 屏幕上的图标/布局应相应更新。 - The users (User A and User B) were on a voice call using Image Share after the transfer has completed: In this case, putting the call on hold means that the picture is no longer shown in the call screen and that the client starting the process has to send a SIP OPTIONS message with a capability update (as described in section 3.6.4.7.2) indicating that the Content Sharing services during a call are no longer available. The on-screen icons/layout should be updated accordingly.
在传输完成后，用户（用户A和用户B）使用图像共享进行语音呼叫：在这种情况下，将呼叫置于保持状态意味着图片不再显示在呼叫屏幕中，并且客户端启动 进程必须发送具有能力更新（如第3.6.4.7.2节所述）的SIP OPTIONS消息，指示呼叫期间的内容共享服务不再可用。 屏幕上的图标/布局应相应更新。 - The users (User A and User B) were on an active Shared Map session: In this case, putting the call on hold means ending the Shared Map session. This can be initiated by either user (User A or User B) depending upon the circumstances. In both cases, a capabilities exchange using SIP OPTIONS occurs and, consequently, the client putting the call on hold should report that the Content Sharing services/capabilities during a call are no longer available.
用户（用户A和用户B）处于活动的共享地图会话：在这种情况下，将呼叫置于保持状态意味着结束共享地图会话。 这可以由用户（用户A或用户B）根据情况启动。 在这两种情况下，使用SIP OPTIONS的能力交换发生，因此，保持呼叫的客户端应该报告呼叫期间的内容共享服务/能力不再可用。 - The users (User A and User B) were on an active Shared Sketch session: In this case, putting the call on hold means ending the Shared Sketch session. This can be initiated by either user (user A or user B) depending upon the circumstances. In both cases, a capabilities exchange using SIP OPTIONS occurs and, consequently, the client putting the call on hold should report that the Content Sharing services/capabilities during a call are no longer available.
用户（用户A和用户B）处于活动的共享草图会话：在这种情况下，将呼叫置于保持状态意味着结束共享草图会话。 这可以由用户（用户A或用户B）根据情况启动。 在这两种情况下，使用SIP OPTIONS的能力交换发生，因此，保持呼叫的客户端应该报告呼叫期间的内容共享服务/能力不再可用。
It should also be noted that from the moment the call is put on hold (that is the call is not active):
还应注意，从呼叫被暂停的那一刻起（即呼叫未激活）：
- It is not necessary to perform the capability exchange described in section 3.6.4.7.2, and,
不需要执行第3.6.4.7.2节中描述的能力交换，并且， - If there is another active call, the behaviour regarding the Image Share, Video Share, Shared Map and Shared Sketch services (that is both for the capability exchange and the services itself) should not be affected by the fact that another call is on hold.
如果存在另一个活动呼叫，则关于图像共享，视频共享，共享映射和共享速记服务（即用于能力交换和服务本身）的行为不应受到另一个呼叫处于保持的事实的影响。
Finally, if the call is made active, this event should be treated as a new call establishment meaning that a capability exchange via OPTIONS needs to occur and, consequently, the relevant on screen icons need to be updated.
最后，如果呼叫被激活，则该事件应当被视为新的呼叫建立，意味着需要经由OPTIONS进行能力交换，因此，需要更新相关的屏幕上图标。
3.6.2.1.3 Waiting call and In-Call sharing services / 等待呼叫和通话共享服务
A waiting call is a non-active call; therefore, consequently with the information presented in section 2.6.3.1, it should not be possible to access the Image Share, Video Share, Shared Map and Shared Sketch services between the caller and receiver.
等待呼叫是非活动呼叫; 因此，根据第2.6.3.1节中提供的信息，不能访问呼叫者和接收者之间的图像共享，视频共享，共享地图和共享草图服务。
Please note having a waiting call will not affect the behaviour for Image Share, Video Share, Shared Map and Shared Sketch services (that is both for the capability exchange and the services itself) on the active call.
请注意，等待呼叫不会影响活动呼叫上的图像共享，视频共享，共享地图和共享草图服务（即功能交换和服务本身）的行为。
3.6.2.1.4 Calls from private numbers / 来自私人号码的来电
When a call is received and the caller cannot be identified (because a hidden number is used for instance), it should not be possible to access the Image Share, Video Share, Shared Map and Shared Sketch services between the caller and receiver.
当接收到呼叫并且无法识别呼叫者（因为例如使用隐藏号码）时，不应该能够访问呼叫者和接收者之间的图像共享，视频共享，共享地图和共享草图服务。
3.6.2.1.5 Call divert/forwarding / 呼叫转移
A receiver may have call divert/forwarding active (the calls are for instance forwarded to another number or to voicemail), it is still possible to access the Image Share, Video Share, Shared Map or Shared Sketch services from the caller to the receiver if, as per section 7.3.1.2 of [3GPP TS 24.279]:
接收者可能具有呼叫转移活动（例如呼叫被转发到另一号码或语音邮件），根据[3GPP TS 24.279]的第7.3.1.2节，其仍然可以访问从呼叫者发给接收者的图像共享，视频共享，共享地图或共享草图服务，如果 ：
- The caller has received a P-Asserted-Identity value from the receiver, or
呼叫者已经从接收者接收到P-Asserted-Identity值，或者 - The caller has received a Connected Number information element and implements the procedure from section 7.3.1.2 of [3GPP TS 24.279].
呼叫者已经接收到连接号码信息元素并且实现[3GPP TS 24.279]的第7.3.1.2节的过程。
Otherwise, it is not possible to access the Image Share, Video Share, Shared Map and Shared Sketch services from the caller to the receiver.
否则，无法访问从呼叫者发给接收者的图像共享，视频共享，共享地图和共享草图服务。
3.6.2.2 Video call / 视频电话
Please refer to section 3.9.2.2.
请参考3.9.2.2节。
3.6.2.3 File Transfer / 文件传输
For sharing files the File Transfer service as described in section 3.5 is used.
对于共享文件，使用文件传输服务，如第3.5节所述。
3.6.3 High Level Requirements / 高级别要求
3.6.3.1 Image Share and Video Share requirements / 图像共享和视频共享要求
3-6-1 Image and Video content can be shared while on a CS or PS Voice call, thus it must be possible to have a voice and a data stream running simultaneously.
3-6-1 在CS或PS语音呼叫时可以共享图像和视频内容，因此必须能够同时运行语音和数据流。
3-6-2 Each time a voice call is established, the user shall be offered the possibility to share image or video content whenever possible.
3-6-2 每次建立语音呼叫时，应尽可能地向用户提供共享图像或视频内容的可能性。
3-6-3 Void
3-6-3 无效
3-6-4 Void
3-6-4 无效
3-6-5 The Image Share and Video Share services shall be unidirectional. During a single Image or Video Share session, the originator of the session can share image or video content with the terminating party, but the terminating party cannot share image or video content with the originator in the same session.
3-6-5 图像共享和视频共享服务应是单向的。在单个图像或视频共享会话期间，会话的发起者可以与终止方共享图像或视频内容，但是终止方不能在同一会话中与发起者共享图像或视频内容。
3-6-6 The receiving party may be offered the possibility to establish a session in the other direction when circumstances allow.
3-6-6 当情况许可时，可以向接收方提供在另一个方向建立会话的可能性。
3-6-7 Void
3-6-7 无效
3-6-8 The Image Share and Video Shareservice can be initiated by either end point involved in the voice call (e.g. the caller or the receiver). When a user initiates image or video sharing, an invitation is automatically sent to the other contact, which may be accepted or rejected. An acceptance shall stand for all the contents shared during the call.
3-6-8 图像共享和视频共享服务可以由语音呼叫中涉及的任一端点（例如，呼叫者或接收者）发起。 当用户发起图像或视频共享时，邀请自动发送到另一联系人，其可以被接受或拒绝。 若接受将代表在通话期间接受共享的所有内容。
3-6-9 For the Image Share and Video Share services, End of communication shall be handled as follows:
3-6-9 对于图像共享和视频共享服务，通信结束处理如下：
- Image or video sharing session termination shall not lead to voice termination.
图像或视频共享会话终止不得导致语音终止。 - Voice call termination shall automatically terminate the sharing session.
语音呼叫终止将自动终止共享会话。
3-6-10 The receiver shall have the possibility to save the shared image or video on his/her device if allowed by the sender.
3-6-10 如果发送者允许，接收者应该有可能在他/她的设备上保存共享图像或视频。
3-6-11 It shall be possible to assign a Service Provider configurable maximum content size allowed to be sent in an Image Share session. This enables the Service Provider of the inviting user’s RCS client to control the maximum size of the content that the inviting user’s RCS client is authorised to send in an Image Share session. The limitation should be transparent to the end-user.
3-6-11 应当能够分配允许在图像共享会话中发送的服务提供商可配置的最大内容大小。 这使得邀请用户的RCS客户端的服务提供商能够控制邀请用户的RCS客户端被授权在图像共享会话中发送的内容的最大大小。 该限制应对最终用户是透明的。
3-6-12 It shall be possible to assign a Service Provider configurable maximum duration time allowed for a Video Share session. This enables the Service Provider of the inviting user’s RCS client to control the maximum duration time of a Video Share session that the inviting user’s RCS client is authorised to handle the limitation should be transparent to the end-user.
3-6-12 可以为视频共享会话分配允许的服务提供商可配置的最大持续时间。 这使得邀请用户的RCS客户端的服务提供商能够控制邀请用户的RCS客户端被授权处理该限制的视频共享会话的最大持续时间应当对最终用户是透明的。
3-6-13 Void
3-6-13 无效
3-6-14 Void
3-6-14 无效
3-6-15 Void
3-6-15 无效
3-6-16 Void
3-6-16 无效
3-6-17 Void
3-6-17 无效
3-6-18 It shall be possible for a terminating party or an originating party to terminate the Image Share or Video Share session.
3-6-18 终止方或始发方可以终止图像共享或视频共享会话。
3.6.3.2 Shared Map and Shared Sketch requirements / 共享地图和共享草图要求
3-6-19 Maps and drawing canvas can be shared while on a CS or PS Voice call, thus it must be possible to have a voice and a data stream running simultaneously.
3-6-19 在CS或PS语音呼叫时可以共享地图和绘图画布，因此必须能够同时运行语音和数据流。
3-6-20 Each time a voice call is established, the user shall be offered the possibility to share map or drawing canvas content whenever possible.
3-6-20 每次建立语音呼叫时，应尽可能地向用户提供共享地图或绘图画布内容的可能性。
3-6-21 Shared Map and Shared Sketch services shall be bidirectional. During a single Shared Map or Shared Sketch session, the originator of the session can share content with the terminating party and the terminating party can share content with the originator using the same session.
3-6-21 共享地图和共享草图服务应为双向的。 在单个共享映射或共享草图会话期间，会话的发起者可以与终止方共享内容，并且终止方可以使用相同的会话与始发者共享内容。
3-6-22 The Shared Map and Shared Sketch service can be initiated by either end point involved in the voice call (e.g. the caller or the receiver). When a user initiates map or drawing canvas sharing, an invitation is automatically sent to the other contact, which may be accepted or rejected. An acceptance shall stand for these contents shared during the call.
3-6-22 共享地图和共享草图服务可以由语音呼叫中涉及的任一端点（例如，呼叫者或接收者）发起。 当用户启动地图或绘图画布共享时，邀请自动发送到其他联系人，可以接受或拒绝。 接受将代表在接受通话期间共享的这些内容。
3-6-23 For Shared Map and Shared Sketch service, end of communication (case of active session while on a voice call) shall be handled as follows:
3-6-23对于共享地图和共享草图服务，通信结束（在语音呼叫时的活动会话的情况）应处理如下：
- Shared Map or Shared Sketch session termination shall not lead to voice termination.
共享地图或共享草图会话终止不会导致语音终止。 - Voice call termination shall automatically terminate the Shared Map or Shared Sketch session.
语音呼叫终止将自动终止共享映射或共享草图会话。
3-6-24 The sender and the receiver should not save the last status of the map shared on his/her device.
3-6-24 发件人和收件人不应保存他/她设备上共享的地图的最后状态。
3-6-25 The sender and the receiver shall have the possibility to save the last status of the sketch shared on his/her device.
3-6-25 发送者和接收者有可能保存在他/她的设备上共享的草图的最后状态。
3.6.3.3 Call composer and post-call service requirements / 呼叫编辑和呼叫后服务要求
3-6-26 It shall be possible to the caller to “compose” pre-call information prior to placing the call and sharing it with the call receiver.
3-6-26 呼叫者可以在发出呼叫并与呼叫接收者共享呼叫前“编辑”呼叫前信息。
3-6-27 It shall be possible to the call receiver to see the composed pre-call information while receiving the incoming call.
3-6-27 当接收到来电时，呼叫接收机应能够看到组成的预呼叫信息。
3-6-28 The pre-call information can be picture file, subject, importance and location.
3-6-28 预呼叫信息可以是图片文件，主题，重要性和位置。
3-6-29 It shall be possible to the caller to “compose” additional information when a call is rejected or unanswered, for the other party to view.
3-6-29 当呼叫被拒绝或未应答时，呼叫者可以“编辑”附加信息，以便另一方查看。
3-6-30 It shall be possible to the party that missed or rejected the call to see the composed post-call information.
3-6-30 有可能错过或拒绝该呼叫的一方看到编辑完的呼叫后信息。
3-6-31 The post-call information can be a note (reason) or a voice message.
3-6-31 呼叫后信息可以是笔记（原因）或语音消息。
3.6.4 Technical Realisation / 技术实现
3.6.4.1 Video Share / 视频共享
Video Share during a voice call shall follow [PRD-IR.74] and take into account the handling of service capabilities and OPTIONS queries defined in sections 2.6.4.1 and 2.6 respectively. Furthermore, to allow the user to accept the sharing on any device a Broadband Access client (see section 2.9.1.4) shall not automatically reject the INVITE request if it is not in a voice call with the sender. It shall, therefore, alert the user as if it was and handle the user’s response as specified in section 2.11.
语音呼叫期间的视频共享应遵循[PRD-IR.74]，并分别考虑第2.6.4.1节和第2.6节中定义的服务能力和OPTIONS查询的处理。 此外，为了允许用户接受在任何设备上的共享，如果宽带接入客户端（参见第2.9.1.4节）不在与发送方的语音呼叫中，它不应当自动拒绝INVITE请求。因此，如果它自动拒绝INVITE请求的话，它应警告用户，并按照第2.11节所述来处理用户响应。
Interworking with Video Share terminals based on legacy specifications (i.e. the “already deployed terminals” option in [PRD-IR.74]) is not applicable in RCS.
基于传统规范（即，[PRD-IR.74]中的“已部署终端”选项）与视频共享终端的互通不适用于RCS。
[PRD-IR.74] mandates that the UE shall populate the P-Preferred-Service header and the network shall populate the P-Asserted-Service header with the Video Share ICSI “urn:urn- 7:3gpp-service.ims.icsi.gsma.videoshare”. 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 Video Share ICSI to SIP requests carrying the +g.3gpp.cs-voice media feature tag in the Accept-Contact header and remove the P-Preferred-Service header field (if present) before further routing the request.
[PRD-IR.74]规定UE应当填充P-Preferred-Service报头，并且网络应该使用视频共享ICSI “urn:urn-7:3gpp-service.ims.icsi.gsma.videoshare”来填充P-Asserted-Service报头。在始发网络中，执行服务断言的S-CSCF或AS将把P-Asserted-Service报头字段设置为断言的视频共享ICSI的值，将其添加到在Accept-Contact头中携带+g.3gpp.cs-voice媒体特征标签的SIP请求，并在进一步路由请求之前删除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.6.4.1.1 Content Share Recording / 内容共享录制
A new SDP attribute in the media level is defined to be used by the Video or Image Share sender to indicate, in the SIP INVITE, to the recipient RCS client that the shared media can be recorded/saved.
媒体级中的新SDP属性被定义为由视频或图像共享发送方使用以在SIP INVITE中向接收方RCS客户端指示可以记录/保存共享媒体。
The new SDP attribute as defined in [IETF-DRAFT-SIPREC-PROTOCOL]:
在[IETF-DRAFT-SIPREC-PROTOCOL]中定义的新的SDP属性：
a=recordpref-attr = "a=recordpref:" pref where pref is set to “nopreference”
a=recordpref-attr = "a=recordpref:" pref，其中pref设置为“nopreference”
An SDP example is a=recordpref:nopreference
SDP示例是a=recordpref:nopreference
If the shared media in a Video or Image Share session is allowed (determined by the sender) to be recorded/saved, the sender RCS client should include the above SDP attribute in the SIP INVITE toward the recipient when setting up the Video or Image Share session. If the shared media in a Video or Image Share session shall not be saved by the recipient RCS client the sender RCS client shall not include the above SDP attribute in the SIP INVITE.
如果在视频或图像共享会话中的共享媒体允许（由发送者确定）被记录/保存，则当建立视频或图像共享会话时，发送者RCS客户端应当在发给接收者的SIP INVITE中包括上述SDP属性。如果视频或图像共享会话中的共享媒体不应由接收方RCS客户端保存，则发送方RCS客户端不应在SIP INVITE中包括上述SDP属性。
A Service Provider can provision its RCS clients to not always include this SDP attribute in the SIP INVITE setting up the Video or Image Share session so the shared media will not be recorded/saved by the recipient RCS client.
服务提供商可以设置其RCS客户端，以便在设置视频或图像共享会话的SIP INVITE中不总是包括该SDP属性，因此共享媒体不会被接收方RCS客户端记录/保存。
If the new SDP attribute is included in the SIP INVITE setting up the Video or Image Share session, it is to the decision of the recipient RCS client (under the instruction of the recipient user or user preference) to determine if the shared media will be recorded/saved.
如果该新的SDP属性被包括在建立视频或图像共享会话的SIP INVITE中，则是由接收方RCS客户端（在接收方用户或用户偏好的指示下）决定是否记录/保存共享媒体。
3.6.4.1.2 Video Interoperability and encoding requirements / 视频互操作性和编码要求
As presented in section 2.6.4.1, the Video Share service availability is mainly dependent on the network coverage. This is based on the assumption that both ends (source and destination) share the ability of handling a common video format and specific profile.
如第2.6.4.1节所述，视频共享服务的可用性主要取决于网络覆盖。 这是基于两端（源和目的地）共享处理公共视频格式和特定简档的能力的假设。
To guarantee the interoperability of RCS clients during Video Share scenarios, all RCS devices supporting the Video Share service shall, at least, support the following video format:
为了保证在视频共享情况下RCS客户端的互操作性，支持视频共享服务的所有RCS设备至少应支持以下视频格式：
- Video format: H.264/MPEG-4 (Moving Pictures Experts Group) Part 10 // AVC (Advanced Video Codec).
视频格式：H.264 / MPEG-4（运动图像专家组）第10部分// AVC（高级视频编解码器）。 - H.264 Profile: Baseline Profile (BP).
H.264简档：基线简档（BP）。 - H.264 Level: 1b[34]
H.264级别：1b [34]
[34] The H.264 baseline profile 1b shall be encoded using the profile-level-id set to 0x42900B and the H.264 Constrained Baseline Profile 1b is 0x42D00B
[34] H.264 baseline profile 1b应使用profile-level-id设置为0x42900B并且H.264 Constrained Baseline Profile 1b为0x42D00B进行编码NOTE: Please note that including this, it is highly recommended to support also the H.263-2000 codec with profile 0 Level 45 which is mandatory in RCS Release 1-4 Video Share that is based on [PRD-IR.74].
注意：请注意，包括此，强烈建议也支持profile 0 Level 45的H.263-2000编解码器，这在基于[PRD-IR.74]的RCS第1-4版中的视频共享中是强制性的。
Next to these mandatory codecs, it is recommended to support additional video formats providing different levels of quality and to use them in an adaptive fashion depending both on the terminal status and the network conditions/coverage. As specified [RFC3264], formats must be listed in order of preference in the SDP media description. As such, additional codecs providing better quality than these mandatory ones should be listed in the SDP before the mandatory codecs. In any case for the encoding of the actual stream should be adapted to the currently available bandwidth and might, therefore, use bitrates lower than the maximum negotiated during session setup. To support this RTCP Receiver Reports (RR) shall be sent at least at a rate of one RR per second.
在这些强制性编解码器旁边，建议支持提供不同级别质量的附加视频格式，并且根据终端状态和网络条件/覆盖范围以自适应方式使用它们。 如[RFC3264]所述，格式必须按照SDP媒体描述中的优先级排列。 因此，在SDP中，提供比这些强制编解码器更好质量的附加编解码器应该在强制编解码器之前列出。 在任何情况下，实际流的编码应该适应于当前可用的带宽，并且因此可以使用比在会话建立期间协商的最大值更低的比特率。 要支持这点，RTCP接收器报告（RR）应至少以每秒一个RR的速率发送。
NOTE: In H.264, support of a certain level implicitly requires support for all lower levels, so a client supporting other H.264 levels should only indicate the highest level per profile that it supports.
注意：在H.264中，支持某个级别隐含需要支持所有较低级别，因此支持其他H.264级别的客户端应仅指示其支持的每个配置文件的最高级别。
Should an RCS terminal support several profiles, the final choice should be based on the outcome of the SDP media negotiation where both ends (sender and receiver) will present the supported video formats at that particular point (that is taking into account each device and network/connectivity status).
如果RCS终端支持多个简档，则最终选择应该基于SDP媒体协商的结果，其中两端（发送方和接收方）将在该特定点呈现支持的视频格式（其考虑每个设备和网络 /连接状态）。
RTP payload handling shall be as described in section 7.4.3 of [3GPP TS 26.114] for the H.264 (AVC) video codec.
RTP有效载荷处理应如在用于H.264（AVC）视频编解码器的[3GPP TS 26.114]的第7.4.3节中所描述的。
The receiving clients should preserve the aspect ratio of the incoming video stream, avoiding that video is stretched to fit the UI. The sending client may redefine the aspect ratio when supporting a flexible handling interface that could alternate between landscape and portrait (e.g. from 4:3 to 3:4 after the sending device has been rotated).
接收客户端应保留传入视频流的宽高比，避免视频被拉伸到适合UI。当支持可以在横向和纵向之间切换的灵活的处理接口（例如，在发送设备被旋转之后，宽高比从4:3变为3:4）时，发送客户端可以重新定义宽高比。
The originator of the Video Share session can indicate support for both Baseline (BP) and Constrained Baseline (CBP) Profiles.
视频共享会话的发起者可以指示对基线（BP）和约束基线（CBP）配置文件的支持。
The originator shall never use Flexible Macroblock Ordering (FMO), Arbitrary Slice Ordering (ASO), or Redundant Slices (RS) features of the profile no matter what the receiving client selects.
无论接收客户端选择什么，发起方都不得使用配置文件的灵活宏块排序（FMO），任意片段排序（ASO）或冗余片段（RS）功能。
When a receiving client that supports both CBP and BP receives the combination of BP and CBP profiles within the same SDP offer it shall select CBP profile when the CBP media format is listed first in the SDP m-line.
当支持CBP和BP两者的接收客户端在相同SDP供给中接收BP和CBP简档的组合时，当在SDP m行中首先列出CBP媒体格式时，其将选择CBP简档。
When the SDP negotiation results in the use of the Baseline Profile (BP), a client shall not send Single-Time Aggregation Packet type A (STAP-A) packets, even when the packetization-mode 1 has been negotiated. When accepting the use of the Constrained Baseline Profile (CBP) a client shall support the use of STAP-A packets when packetization- mode 1 was negotiated.
当SDP协商导致使用基线简档（BP）时，即使已经协商了分组化模式1，客户端也不应当发送单时间聚合分组类型A（STAP-A）分组。 当接受约束基线简档（CBP）的使用时，客户端应支持在协商模式1的分组模式时使用STAP-A分组。
v=0
o=- 1323909835 1323909838 IN IP4 x.x.x.x
s=-
c=IN IP4 x.x.x.x
t=0 0
m=video 4284 RTP/AVP 118 119
a=sendrecv
a=rtpmap:118 H264/90000
a=fmtp:118 packetization-mode=1;profile-level-id=42d00b
a=rtpmap:119 H264/90000
a=fmtp:119 packetization-mode=1;profile-level-id=42900b
Table 44: Example of a VideoShare SDP Offer with both CBP and BP profiles, each using Level 1b, preference for CBP since it is first in m-line / 表44：具有CBP和BP简档的视频共享SDP Offer的示例，均使用级别1b，偏好CBP，因其为m线第一设置
Coordination of Video Orientation (CVO) as specified in 3GPP Release 12 [3GPP TS 26.114] shall be supported with two (2) bits granularity by the UE and the entities in the IMS core network which terminate the user plane. The support for CVO shall be included in SDP offer and SDP answer as specified in section 6.2.3 of [3GPP TS 26.114].
3GPP版本12 [3GPP TS 26.114]中规定的视频定向协调（CVO）将由UE和IMS核心网络中终止用户平面的实体以两（2）比特粒度来支持。 对CVO的支持应包括在[3GPP TS 26.114]的6.2.3节中规定的SDP offer和SDP answer中。
3.6.4.1.3 Video Interoperability in LTE/HSPA / LTE/HSPA中的视频互操作性
Video Share used over high bandwidth connections such as LTE or HSPA allows high bitrate bearers, thus allowing better user experience e.g. when using a large screen.
通过高带宽连接（如LTE或HSPA）使用的视频共享允许高比特率承载，从而允许更好的用户体验（例如：当使用大屏幕时）。
As specified in [PRD-IR.74], an RCS device shall support the H.264 video codec with baseline (and optionally Constrained Baseline Profile) profile and level 1.3[35] to provide 768 kilobits per second (kbps) video over an LTE bearer or over a similar high bitrate bearer. Please note that this codec is considered in addition to the mandatory formats specified in section 3.6.4.1.2.
如[PRD-IR.74]中所规定，RCS设备应当支持具有基线（以及可选的约束基线简档）简档和级别1.3 [35]的H.264视频编解码器，以通过LTE承载或在类似的高比特率承载提供768千比特每秒（kbps）的视频。 请注意，除了第3.6.4.1.2节中规定的强制格式之外，还要考虑此编解码器。
[35] The H.264 baseline profile 13 shall be encoded using the profile-level-id set to 0x42800D. For H.264 CBP level 1.3 it is 0x42C00D.
[35] H.264基线配置文件13应使用profile-level-id设置为0x42800D进行编码。 对于H.264 CBP级别1.3，它是0x42C00D。
If a second Video Share session is established in parallel, the H.264 video codec with baseline profile (and optionally Constrained Baseline Profile) and level 1.2[36] shall be used instead. The assumption for the use of a high bitrate bearer is that the connectivity and video parts of both terminals support it and have LTE or another high bitrate broadband access; otherwise the video bitrate will be reduced to the level 1b (as presented in section 3.6.4.1.2) to assure compatibility.
如果并行建立第二个视频共享会话，则应使用具有基准配置文件（以及可选的约束基准配置文件）和级别1.2 [36]的H.264视频编解码器。 使用高比特率载波的假设是两个终端的连接和视频部分支持它并且具有LTE或另一高比特率宽带接入; 否则视频比特率将降低到级别1b（如第3.6.4.1.2节所述），以确保兼容性。
[36] The H.264 baseline profile 12 shall be encoded using the profile-level-id set to 0x42800C. For H.264 CBP level 1.2 it is 0x42C00C.
[36] H.264基准配置文件12应使用profile-level-id设置为0x42800C进行编码。 对于H.264 CBP级别1.2，它是0x42C00C。
Also, in this case the encoding of the actual stream should be adapted to the currently available bandwidth and might therefore use bitrates lower than the maximum negotiated during session setup. Furthermore, in this case CVO as specified in 3GPP Release 12 [3GPP TS 26.114] shall be supported with two (2) bits granularity by the UE and the entities in the IMS core network which terminate the user plane. The support for CVO shall be included in SDP offer and SDP answer as specified in section 6.2.3 of [3GPP TS 26.114].
此外，在这种情况下，实际流的编码应当适应于当前可用的带宽，并且因此可以使用比在会话建立期间协商的最大值更低的比特率。 此外，在这种情况下，3GPP版本12 [3GPP TS 26.114]中规定的CVO将由UE和IMS核心网络中终止用户平面的实体以两（2）比特粒度来支持。 对CVO的支持应包括在[3GPP TS 26.114]的6.2.3节中规定的SDP offer和SDP answer中。
3.6.4.1.4 Video Share duration / 视频分享时长
A configurable parameter allows the Service Provider to set the maximum duration of a Video Share session (see VS MAX DURATION in section A.1.6) in the UE. When one of the UEs which are sharing a live video stream detects that the maximum duration is reached, it shall tear down the Video Share session by sending a SIP BYE request. When sharing a live video stream, if the sharing duration (send or receive) is approaching the duration limitation, a warning notification could be displayed for prompting the two UEs. When sharing a stored video, if the UE detects that the video file being shared exceeds the Service Provider’s configured maximum duration, it shall either not set up the session or tear it down depending on whether it is the initiator or the receiver.
可配置参数允许服务提供商设置UE中的视频共享会话的最大持续时间（参见章节A.1.6中的VS MAX DURATION）。 当共享实况视频流的UE之一检测到达到最大持续时间时，它将通过发送SIP BYE请求来拆除视频共享会话。 当共享实况视频流时，如果共享持续时间（发送或接收）接近持续时间限制，则可以显示警告通知以提示两个UE。 当共享存储的视频时，如果UE检测到共享的视频文件超过服务提供商的配置的最大持续时间，则它将不建立会话或者根据其是发起方还是接收方而将其拆除。
3.6.4.2 Image Share / 图像共享
Image Share during a voice call shall follow [PRD-IR.79] where the SIP OPTIONS query shall be handled as specified in section 2.6 of this document. Furthermore, to allow the user to accept the sharing on any device a broadband access client (see section 2.9.1.4) shall not automatically reject the SIP INVITE request if it is not in a voice call with the sender. It shall alert the user and handle the user’s response as specified in section 2.11.
在语音通话过程中的图像分享应当遵循[PRD-IR.79]，其中，SIP OPTIONS应按照本文的第2.6节中的规定处理。此外，为了使用户在任何设备上接受该共享，如果不在与发送者的语音呼叫中，一个宽带接入客户端（见2.9.1.4节）不应自动拒绝SIP INVITE请求。如2.11节所述，其应当提醒用户，并处理用户的响应。
To ensure that the request is sent to all devices with equal priority, clients using a PS voice service as defined in section 3.8 shall include the +g.3gpp.cs-voice feature tag in the Accept-Contact and Contact headers of the SIP INVITE request for content sharing. As described in [PRD-IR.79] the Image Share IARI is also included in the Accept-Contact and Contact headers (see Table 6 in section 2.6.1.1.2).
为确保请求被发送到具有相同优先级的所有设备，使用第3.8节中定义的PS语音服务的客户端应在SIP INVITE的Accept-Contact和Contact头中包含+ g.3gpp.cs-voice功能标记 请求内容共享。 如[PRD-IR.79]中所述，图像共享IARI也包括在Accept-Contact和Contact头中（参见在2.6.1.1.2节中的表6）。
If the UE detects that the file being transferred exceeds the Service Provider configured maximum size (see IS MAX SIZE in section A.1.6), it shall either not set up the session or tear it down depending on whether it is the initiator or the receiver.
如果UE检测到正在传送的文件超过服务提供商配置的最大大小（参见A.1.6节中的IS MAX SIZE），则它将不建立会话或根据它是发起方还是接收方将其拆除 。
NOTE: All RCS services using MSRP, including Image Share, shall align with MSRP usage as described in section 2.8.
注意：使用MSRP的所有RCS服务（包括图片共享）应与第2.8节中描述的MSRP使用一致。
Details for image format as specified in [3GPP TS 26.141] will be followed.
将遵循[3GPP TS 26.141]中规定的图像格式的细节。
[PRD-IR.79] mandates that the UE Shall populate the P-Preferred-Service header and the network shall populate the P-Asserted-Service header with the OMA CPM Standalone Messaging – Large Message Mode ICSI “urn:urn-7:3gpp- service.ims.icsi.oma.cpm.largemsg”. 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 Standalone Messaging – Large Message Mode ICSI to SIP requests carrying the +g.3gpp.iari-ref=”urn%3Aurn-7%3A3gpp-service.ims.iari.gsma-is” IARI feature tag and value in the Accept-Contact header and remove the P-Preferred-Service header field (if present) before further routing the request.
[PRD-IR.79]强制UE应填充P-Preferred-Service报头，并且网络应填充P-Asserted-Service报头，填充使用OMA CPM独立消息 - 大消息模式ICSI “urn:urn-7:3gpp-service.ims.icsi.oma.cpm.largemsg“。在始发网络中执行服务断言的S-CSCF或AS，将向SIP请求添加P-Asserted-Service报头字段，该字段设置为断言的CPM独立消息-大消息模式ICSI，该SIP请求的Accept-Contact报头字段中需携带+g.3gpp.iari-ref=“urn%3Aurn-7%3A3gpp-service.ims.iari.gsma-is”这一IARI特征标记和值，还需要在进一步路由请求之前删除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.6.4.3 Call composer / 呼叫编辑
The technical realisation is based on procedures covered in sections 2.3 and 2.4 of [PRD-RCC.20].
技术实现基于[PRD-RCC.20]第2.3节和第2.4节所述的程序。
3.6.4.4 Post-call service / 呼叫后服务
The technical realisation is based on procedures covered in sections 2.3 and 2.5 of [PRD-RCC.20].
技术实现基于[PRD-RCC.20]第2.3节和第2.5节所述的程序。
3.6.4.5 Shared Map / 共享地图
The technical realisation is based on procedures covered in section 2.9.7 and 2.9.9 and 2.9.10 of [PRD-RCC.20].
技术实现基于[PRD-RCC.20]第2.9.7节和第2.9.9节和第2.9.10节中所述的程序。
3.6.4.6 Shared Sketch / 共享草图
The technical realisation is based on procedures covered in section 2.9.8, 2.9.9 and 2.9.10 of [PRD-RCC.20].
技术实现基于[PRD-RCC.20]第2.9.8,2.9.9和2.9.10节中所述的程序。
3.6.4.7 Image Share and Video Share flows / 图像共享和视频共享流
3.6.4.7.1 General assumptions / 一般假设
In the following sections, we will show the relevant message flows and reference UX. Please note that the following assumptions have been made:
在以下部分中，我们将显示相关的消息流和参考UX。 请注意，已做出以下假设：
- For simplicity, the internal mobile network interactions are omitted in the diagrams shown in the following sections.
为了简单起见，在以下部分中显示的图中省略了内部移动网络交互。 - The terminal and the network support 2G DTM and it is, therefore, always possible to gracefully terminate the content sharing session related to a voice call provided the terminal remains switched on. If 2G DTM is not supported, the case where on one of the ends a handover occurs to 2G would be result in behaviour towards the other end and the network that is equivalent to the one described for the case of a client error.
终端和网络支持2G DTM，并且因此，如果终端保持开启，则总是可以平静地终止与语音呼叫相关的内容共享会话。 如果不支持2G DTM，则在其中一端发生到2G的切换的情况将导致朝向另一端和网络的行为，其等效于对于客户端错误的情况所描述的行为。 - The device is in coverage supporting bi-directional Video Share (see section 2.7). If this were not the case, additional capability exchanges would be required when starting and terminating a sharing session to indicate respectively that the device cannot handle an incoming Video Share session and that it can handle such an incoming Video Share session again.
设备在支持双向视频共享（参见第2.7节）的覆盖范围内。 如果不是这种情况，则当开始和终止共享会话以分别指示设备不能处理传入的视频共享会话并且其可以再次处理这样的传入视频共享会话时，将需要附加的能力交换。 - The terminal comes with a front and rear camera. If one or both are missing, the user should be notified only with the available options.
终端配有前置和后置摄像头。 如果缺少一个或两个，应该只通知用户可用的选项。 - Prior to a voice call, the user accessed the client’s address book, call log or dial-pad to make the call. As described in section 2.6, while these actions are performed a capability query is executed to double-check on the available capabilities. As in older RCS versions including in some non RCS clients, Video and Image Share services are only available in a call, an OPTIONS exchange is required once the call is established to check on the capabilities during a call. This exchange can be initiated by either the sender or the receiver. In the following diagrams, it is assumed that this initial exchange (OPTIONS and response) has already taken place, and therefore, both ends are aware of the capabilities and the available RCS services.
在语音呼叫之前，用户访问客户端的地址簿，呼叫日志或拨号盘以进行呼叫。 如第2.6节所述，在执行这些操作时，将执行能力查询以重复检查可用功能。 与旧的RCS版本（包括在一些非RCS客户端中）一样，视频和图像共享服务仅在呼叫中可用，一旦建立呼叫就需要OPTIONS交换以在呼叫期间检查能力。 此交换可以由发送方或接收方发起。 在下面的图中，假设这个初始交换（OPTIONS和响应）已经发生，因此，两端都知道能力和可用的RCS服务。 - In the diagrams, it is assumed for simplicity that MSRP chunking is enabled. This is for representation purposes and it is up to the OEM to decide whether MSRP chunking is enabled or not.
在图中，为了简单起见假设MSRP组块被启用。 这是为了表示目的，由OEM决定是否启用MSRP分块。 - The flows in Figure 66, Figure 67, Figure 68, Figure 69, Figure 70, Figure 71, Figure 72, Figure 74, Figure 75 and Figure 76 show an OPTIONS exchange at the end of the flow. If the capability exchange is done using Presence, the equivalent Presence mechanism will be used.
图66，图67，图68，图69，图70，图71，图72，图74，图75和图76中的流程示出了在流程结束时的OPTIONS交换。 如果使用存在来完成能力交换，则将使用等效的存在机制。
3.6.4.7.2 Exchange capabilities during a call / 呼叫期间的交换功能
The assumptions in this case are that User A and B are on a call when the capabilities of one of the users change (due to a hand-over to a different data carrier for instance). Therefore, the other end has to be informed using the OPTIONS message[37]
在这种情况下的假设是，当一个用户的能力改变（例如由于切换到不同的数据载体）时，用户A和B正在呼叫。 因此，另一端必须使用OPTIONS消息[37]
[37] The SDP information included in the response to the OPTIONS request is required due to the compliancy to [PRD-IR.74]. This will only be used during OPTIONS exchanges related to a call. The Video Share service shall only be considered to be available if at least one codec in the received SDP is supported by the client.
[37] 由于对[PRD-IR.74]的遵守，需要包含在对OPTIONS请求的响应中的SDP信息。 这将仅在与呼叫相关的OPTIONS交换期间使用。 只有在客户端支持所接收的SDP中的至少一个编解码器时，视频共享服务才应被视为可用。
Figure 64: Capabilities exchange during a call / 图64：呼叫期间的能力交换
3.6.4.7.3 Share video / 分享视频
The assumptions in this case are that both User A (wanting to share video) and User B (recipient wanting to receive it), have successfully performed the capability query, as shown in section 3.6.4.7.2. Therefore, both clients are aware that video sharing is possible (both UEs on a 3G+ or Wi-Fi).
在这种情况下的假设是，用户A（想要共享视频）和用户B（希望接收它的接收者）都成功地执行了能力查询，如第3.6.4.7.2节所示。 因此，两个客户端都知道视频共享是可能的（3G +或Wi-Fi上的UE）。
In this case, RTP is the protocol used to stream the video data, so it can be re-produced in real-time on the other end.
在这种情况下，RTP是用于流传输视频数据的协议，因此它可以在另一端实时重新产生。
Figure 65: Share Video / 图65：共享视频
3.6.4.7.4 Stop sharing video (RTP): Sender initiated / 停止共享视频（RTP）：发送者启动
The assumptions in this case are that User A is sharing a video (through RTP) with User B. However, User A no longer wants to keep sharing it.
在这种情况下的假设是用户A正在与用户B共享视频（通过RTP）。然而，用户A不再希望继续共享它。
Figure 66: Sender stops sharing video / 图66：发送者停止共享视频
3.6.4.7.5 Stop sharing video (RTP): Receiver initiated / 停止共享视频（RTP）：接收者启动
This case is equivalent to the previous one. However, it is the receiver (User B) who does not want to keep receiving the video.
这种情况与前一个相当。 然而，接收者（用户B）不想继续接收视频。
Figure 67: Receiver wants no longer to receive video / 图67：接收者不再接收视频
3.6.4.7.6 Stop sharing video (RTP) as the required capability is no longer available / 停止共享视频（RTP），因为所需的功能不再可用
The assumptions in this case are that User A is sharing video (RTP) with User B, and either User A or User B is no longer capable (for instance because the terminal is busy, suddenly has no LTE, 3G+ or Wi-Fi coverage available without triggering an IP reconfiguration or loss of connection) of sending or receiving a video. Please note that in the example, it is assumed that the sender (User A) is the one losing the capability. This sequence will be equivalent if:
在这种情况下的假设是用户A与用户B共享视频（RTP），并且用户A或用户B不再能够（例如因为终端忙，突然没有LTE，3G +或Wi-Fi覆盖 可用，而不触发IP重新配置或丢失连接）发送或接收视频。 请注意，在示例中，假设发送方（用户A）是失去能力的人。 这个顺序将是等效的，如果：
- The receiver (User B) loses the capability to receive video: The BYE and OPTIONS exchange would be initiated by the receiver (User B) in this case.
接收器（用户B）失去接收视频的能力：在这种情况下，BYE和OPTIONS交换将由接收器（用户B）发起。 - Both lose the capability to share video: The BYE and OPTIONS exchange message would be initiated by the client that is the first one to lose the capability in this case.
两者都失去了共享视频的能力：BYE和OPTIONS交换消息将由客户端发起，这是在这种情况下失去能力的第一个。
In losing the capability to send video, the case in which there is an IP reconfiguration is excluded. Please note that this particular case is covered under the “Client Error” section later in this section (see 3.6.4.7.12 and 3.6.4.7.13).
在丢失发送视频的能力时，排除了存在IP重新配置的情况。 请注意，此特定情况将在本节后面的“客户端错误”部分（参见3.6.4.7.12和3.6.4.7.13）中介绍。
Figure 68: Video can no longer be shared (capability not available) / 图68：视频无法再共享（功能不可用）
3.6.4.7.7 Share pictures during a call / 在通话过程中分享照片
The assumptions in this case are that both User A (wanting to share picture) and User B (recipient wanting to receive it), have successfully exchanged the OPTIONS messages. Therefore, both clients are aware that Image Share is possible (that is both UEs are on an LTE, 3G+ or Wi-Fi network).
在这种情况下的假设是用户A（想要共享图片）和用户B（收件人想要接收它），已经成功地交换了OPTIONS消息。 因此，两个客户端都知道图像共享是可能的（即，两个UE都在LTE，3G +或Wi-Fi网络上）。
Figure 69: Sharing a picture during a call / 图69：在通话期间共享图片
3.6.4.7.8 Stop sharing a picture during a call: Sender initiated / 在通话期间停止共享图片：发送者启动
The assumptions in this case are that User A is sharing a picture with User B, the transfer is still ongoing, but User A no longer wants to keep sharing the picture.
在这种情况下的假设是用户A与用户B共享图片，传送仍在进行中，但用户A不再希望继续共享图片。
Figure 70: Sender stops sharing a picture during a call / 图70：发送者在通话期间停止共享图片
3.6.4.7.9 Stop sharing a picture during a call: Receiver initiated / 在通话期间停止共享图片：接收者启动
This case is equivalent to the previous one. It is, however, the receiver (User B) who does not want to keep receiving the picture.
这种情况与前一个相当。 然而，接收者（用户B）不想继续接收图片。
Figure 71: Receiver stops picture sharing / 图71：接收者停止图像共享
3.6.4.7.10 Stop sharing a picture during a call as the required capability is no longer available / 在通话期间停止共享图片，因为所需的功能不再可用
The assumptions in this case are that User A is sharing a picture with User B, the transfer has not yet finished, and either User A or User B are no longer capable (for instance because the terminal is busy) to sharing or receiving the image respectively. Please note that in the example it is assumed that the sender (User A) is the client losing the capability. The sequence will be equivalent however for:
在这种情况下的假设是用户A与用户B共享图片，传送尚未完成，并且用户A或用户B不再能够（例如因为终端忙）分别共享或接收图像。请注意，在该示例中，假设发送方（用户A）是失去能力的客户端。 然而，该序列将等效于：
- The Receiver (User B) losing the capability to receive pictures: The BYE and OPTIONS exchange would be initiated by the receiving client (User B) in this case.
接收者（用户B）失去接收图像的能力：在这种情况下，BYE和OPTIONS交换将由接收客户端（用户B）发起。 - Both lose the capability to share pictures: The BYE and OPTIONS exchange would be initiated by the first client to lose the capability in this case.
两者都失去共享图片的能力：BYE和OPTIONS交换将由在这种情况下失去能力的第一个客户端发起。
Please note that there is an exception to stop a file transfer due to capabilities. If one of the users is left with 2G coverage (on a DTM terminal) once a transfer has started, the transfer may continue until completed, provided the handover did not trigger an IP bearer reconfiguration. Once the transfer is completed however, picture sharing will no longer be available as a service during the call.
请注意，由于功能，停止文件传输有一个例外。 如果一旦转移已经开始，则用户中的一个留在2G覆盖（在DTM终端上），则如果切换没有触发IP承载重配置，则转移可以继续直到完成。 然而，一旦传输完成，图片共享将不再作为服务在呼叫期间可用。
Figure 72: A picture can no longer be shared during a call (capability not available) / 图72：在呼叫期间无法再共享图片（功能不可用）
3.6.4.7.11 Decline share video or picture / 拒绝分享视频或图片
User A wants to share a video or picture with User B. User B, however, does not want to receive it. Please note that it is assumed that both Video and Image Share is possible (that is the proper capabilities are available).
用户A想要与用户B共享视频或图片。然而，用户B不想接收它。 请注意，假设视频和图像共享都是可能的（即是说正确的功能可用）。
Figure 73: User declines sharing a picture during a call / 图73：用户拒绝在通话期间共享图片
3.6.4.7.12 Non-graceful termination (sender): Video or picture sharing / 非优雅终止（发送者）：视频或图片共享
In this case, User A is sharing video or a picture with User B. Suddenly, User A’s connection to the network fails (This may for instance be due to a client error, a reboot of the device, the loss of the data bearer, a switch in data carrier [for instance 3G+ to 3G] causes an IP layer reconfiguration and so on).
在这种情况下，用户A正在与用户B共享视频或图片。突然，用户A到网络的连接失败（这可能例如由于客户端错误，设备重新启动，数据承载的丢失， 数据载体的切换[例如3G+到3G]导致IP层重新配置等等）。
In the following flow, it is assumed a video transfer (RTP) was taking place. It will be equivalent however to the case an MSRP transfer (Image Share or video sharing via File Transfer) was taking place and was not finished:
在下面的流程中，假设正在进行视频传输（RTP）。 然而，它将等效于MSRP传输（图像共享或通过文件传输的视频共享），并且尚未完成：
Figure 74: Non-graceful termination (sender) for video / 图74：视频的非优雅终止（发送者）
3.6.4.7.13 Non-graceful termination (receiver): Video or picture sharing / 非优雅终止（接收者）：视频或图片共享
To protect the IMS Core network from cases where both the sender and the receiver become unresponsive or unreachable before they had time to terminate the SIP session, the RCS Client shall use the procedure described in [RFC4028] in a similar way to the one mandated in [RCS-SIMPLEIM-ENDORS], that is the RCS client initiating a SIP session must request the role of refresher and the option tag 'timer' must be included in a Supported header.
有时，发送方和接收方在它们有足够时间终止SIP会话之前会变得不响应或不可到达，为了保护IMS核心网络免于这种情况，对于[RCS-SIMPLEIM-ENDORS]中定义的的情况，RCS客户端将使用与[RFC4028]中描述的过程类似的方式完成，即启动SIP会话的RCS客户端必须请求刷新器的角色，并且选项标签“timer”必须包括在支持的报头中。
The Session-Expires and Min-SE values announced by an RCS client must be configurable by the Service Provider.
由RCS客户端公布的Session-Expires和Min-SE值必须由服务提供商配置。
This use case is identical to the previous use case, except that in this instance User B (receiver) loses the ability to receive/process MSRP messages (this can for example be due to a client error, a reboot of the device, a loss of the data bearer and so on).
该用例与先前的使用情况相同，除了在这种情况下用户B（接收器）失去接收/处理MSRP消息的能力（举例来说，这可以是由于客户端错误，设备重新启动，数据承载的丢失等等）。
In the first flow diagram it is assumed that an Image Share transaction was taking place through MSRP:
在第一个流程图中，假设通过MSRP进行图像共享事务：
Figure 75: Non-graceful termination of picture sharing during a call / 图75：在呼叫期间非正常终止图片共享
In the second flow it is assumed that a Video Share transaction was taking place through RTP:
在第二个流程中，假设通过RTP进行视频共享事务：
Figure 76: Non-graceful termination of video sharing during a call / 图76：在呼叫期间视频共享的非正常终止
3.6.4.8 Call Composer flows / 呼叫编辑流程
Flows related to Call Composer service are provided in Annex B of [PRD-RCC.20].
与呼叫编辑服务相关的流程在[PRD-RCC.20]的附件B中提供。
3.6.5 NNI and IOT considerations / NNI和IOT的考虑
The NNI interfaces for content sharing services shall behave according to the procedures described in section 2.12 and referred documents.
内容共享服务的NNI接口应根据2.12节和参考文档中描述的过程进行操作。
3.6.6 Implementation guidelines and examples / 实施指南和示例
3.6.6.1 Image, video, map or drawing canvas sharing during a call / 在通话期间的图像，视频，地图或绘图画布共享
As this is about sharing during a call, for both the sender and the receiver the sharing always starts from the call screen where the capabilities for sharing to the conversation partner in the voice call are shown. The user can then select one of the available services after which they will select the source of the sharing. A session will then be set up and the user will see the content that is being shared.
由于这是关于在呼叫期间共享，对于发送者和接收者，共享总是从呼叫屏幕开始，其中示出了用于在语音呼叫中与会话伙伴共享的能力。 然后，用户可以选择可用服务中的一个，之后他们将选择共享的源。 然后将建立会话，用户将看到正在共享的内容。
3.6.1.1.1 Video Share / 视频共享
The description above leads to following user experience for the initiator of a Video Share:
上述说明为视频共享的发起者提供了以下用户体验：
Figure 77: Reference UX for Video Share during a call (initiator) / 图77：呼叫期间视频共享的参考UX（发起者）
A user invited for Video Share during a call first receives an additional invitation and if they accept, they are shown the video with the possibility to stop the sharing:
在通话期间邀请观看视频分享的用户首先会收到一个附加邀请，如果他们接受邀请，他们就会看到该视频，他们也可能停止共享：
Figure 78: Reference UX for Video Share during a call (recipient) / 图78：通话期间视频共享的参考UX（收件人）
NOTE: When the receiver accepts the sharing from the device that is involved in the voice call this acceptance applies automatically to all further sharing requests during that call.
注意：当接收方接受来自语音呼叫中涉及的设备的共享时，此接受在该呼叫期间自动应用于所有进一步的共享请求。
3.6.6.1.2 Image Share / 图像共享
For Image Share, the experience is similar than the one for Video Share shown in section 3.6.6.1.1. As it requires the transfer of a large file before something can be displayed rather than being able to stream immediately, there is a transfer delay. This leads to the following user experience for the sender:
对于图像共享，体验类似于3.6.6.1.1中所示的视频共享体验。 由于它需要在显示大量文件之前传输大文件，而不是立即流式传输，因此存在传输延迟。 这将为发件人带来以下用户体验：
Figure 79: Reference UX for Image Share during a call (sender) / 图79：呼叫期间图像共享的参考UX（发件人）
A user invited for Image Share during a call first receives an additional invitation and if they accept, they are shown the image with the possibility to stop the transfer initially and stop displaying the image once transferred:
在通话期间邀请了图像共享的用户首先接收到另一个邀请，如果他们接受，则他们被显示的图像可能最初停止传输，并在传输后停止显示图像：
Figure 80: Reference UX for Image Share during a call (receiver) / 图80：通话期间图像共享的参考UX（接收者）
NOTE: When the receiver accepts the sharing from the device that is involved in the voice call this acceptance applies automatically to all further sharing requests during that call.
注意：当接收方接受来自语音呼叫中涉及的设备的共享时，此接受在该呼叫期间自动应用于所有进一步的共享请求。