1. History

Peer-to-peer video sharing was introduced by Nokia phones first in 2004. This was a proprietary solution on top of a SIP or IMS infrastructure. Some European operators offered commercial services based on these phones already in 2005. Similar services popped under the names of See What I See, Rich Voice Call, Push-to-Video (P2video or PTV), etc.

The GSMA Video Share service ^[1] was originally defined, implemented and tested during the Session Initiation Protocol (SIP) trials conducted by the GSM Association in 2005/2006. During the SIP trials, the Video Share service used to demonstrate IMS interworking over SIP.^[2] Video Share was also tested on the IPX ^[3] to prove that the service might become universally available in the future.

Subsequently, GSMA decided to create a separate project for Video Share. Phase 1 of the Video Share project built on and leveraged the results from the SIP trials. Service definition for the first phase of the Video Share project was completed in September/October 2006. Mobile operators worldwide, such as AT&T, have deployed the Video Share service ^[4] based on the Phase 1 service definition. An interoperability technical reference specification for Video Share ^[5] is also available from GSMA.

Phase 2 of the GSMA Video Share project was kicked off in May/June 2007 and is currently in progress.

2. Differences Between Video Share and Video Call

Video Share is sometimes confused with traditional two-way Video Call service. Video Call involves simultaneous two-way Video and Audio transmission between the 2 parties (from start to finish), whereas Video Share involves adding and removing one or more one-way Video sessions to an existing voice call between the 2 parties. There are other subtle differences between the two services as far as the user experience is concerned:

1. In a Video Call, the intent is known upfront. Parties on the call are fully aware that they are involved in a video call. The caller initiates the call as a Video Call, and the length of the video is tied to the length of the voice call. By contrast, a Video Sharing session starts as a normal voice conversation, and depending on the conversation, it may lead to one party sharing something with the other party while they talk about it (e.g. a new car, the snow outside, a video clip of kids). A 3-4 minute voice call may involve a minute of Video Sharing.
2. Video Sharing has no privacy implications for the recipient since the sharing of video is one-way. The camera on the sender’s mobile phone is usually pointed at some object or activity that he/she wants to share with the recipient. On the other hand, Video Calling has historically been “I see you, you see me” type of service where the camera is pointed at the parties on the call (e.g., videophone, webcam).
3. Display screen on a mobile phone has limited real estate. Splitting the screen into Picture-in-Picture (in order to display both sending and received video streams) significantly degrades the Video Call user experience on a mobile phone (Video Call with Picture-in-Picture is effective in corporate applications such as video conferencing where a large screen is used).

Extensions to Video Share include Video Clip Sharing, where a video clip recorded on the phone (or resident in the network) can be shared between two parties – something not delivered in a typical Video Call implementation.

3. Architecture

The Phase 2 Video Share solution consists of a Client Application running on mobile handsets and an Application Server deployed in the mobile network. The Phase 1 Video Share architecture does not include an Application Server, i.e. media is transferred directly between the terminals. The Video Share service uses the standard IMS Core infrastructure to transmit signaling and media traffic. IP Packet Exchange (IPX) proxies may be part of this infrastructure to allow interconnection between operators and to provide a collection point for session accounting records used for inter-operator traffic charging. https://handwiki.org/wiki/index.php?curid=1175453

3.1. Video Share Client

The Video Share (VS) Client is a software application running on the mobile handset. Typically, the Video Share Client is implemented as a native application running on mobile operating systems such as Windows Mobile, Symbian, Linux, and proprietary RTOS. VS-compliant handsets contain an ISIM/USIM properly provisioned with IMS public/private identities and access credentials. A user’s subscription is usually bound to their smart card (ISIM/USIM) such that the Video Share service is portable in the sense that the user may be able to send and receive video share on any capable handset.

The Video Share Client supports SIP and RTP/RTCP transmission. SIP is used for call control and signaling, and RTP/RTCP is used for video transmission. Functionality supported by a GSMA Video Share Client includes:

• Registration, Authentication and Video Share initiation
  • IMS registration upon power up using IMS access credentials stored in the ISIM/USIM
  • Video Share Capability Exchange prior to the initiation of a video share call using SIP, including the codecs supported
  • Display icon indicating the capability status of the other device (that is, whether the other device is VS capable or not)
  • Ability for the user to start and stop a VS session. The called party has the option to accept or reject a video stream at the start of the session
• Usability
  • Privacy policies that allow users to block other users from performing a Capability Exchange with their device and/or streaming video to their device
  • Ability for either a transmitting or receiving device to terminate a VS session at any point during the session
  • Ability for both transmitting and receiving devices to display the video that is being streamed
• Codec Support
  • H.263 Profile 0 (Level 10). Support for other codecs is desired but optional
  • Support for H263-2000 RTP payload format
  • Support for RTCP sender and receiver reports

3.2. Video Share Application Server

The Video Share Application Server is an IMS Application Server that interfaces with the S-CSCF network element in the IMS network through the 3GPP-defined ISC interface. The Application Server supports the SIP Back-to-Back User Agent (B2BUA) call control architecture that enables service policy control and enforcement capabilities of the video share session. The Video Share Application Server typically runs on a carrier grade fault tolerant hardware platform.

Functionality supported by the Video Share Application Server includes:

• Video Share Service Control. The Application Server provides a central point for service control, provisioning and configuration in the network; and for enforcing service policies such as admission control and registration control. Operator-defined subscriber and service policies can be enforced even if a subscriber has modified the policy on his/her handset. Policies can be enforced by the Server in real time, or during session establishment by ensuring that the policy on the handset matches the operator-defined policy stored on the Server, In some cases, this might require overwriting the policy on the handset with that on the Server. A server-based application server will enforce access control and charging policies based on the following triggers:
  • Inbound roaming access (mobile originating subscriber requests session from a visited network)
  • Outbound roaming access (session request to a mobile terminating subscriber located in visited network)
  • Home network access
  • Access network type (UMTS, Wi-Fi or both)
  • Time-sensitive promotional period (peak, off-peak or promotional time period)
  • IMSI or Public User Identifier (PUID) of calling or called user
  • Location area of calling or called user
  • Mobile originating or mobile terminating direction (send-only, receive-only or both)
• Once these trigger conditions are met, Video Share session control policies, such as the following, can be applied:
  • Call Termination
  • Call Barring
  • Call Gapping
  • Video Stream Quality Enforcement
  • Support for point-to-multipoint video share sessions by setting up multiple legs for a video share session
• Enable interoperability between different clients/endpoint devices by providing client normalization functions such as (a) protocol conversion, (b) video transcoding, and (c) rate adaptation
• Enhanced charging capabilities. The Application Server can be configured to include parameters in the charging records that are specific to the Video Share service. The Application Server makes it possible to support a range of charging plans.
• Detailed Statistics including:

1. Session statistics including those established, terminated, initiated, and failed
2. User registration statistics including those registered, de-registered, registration rejected
3. Active Call Detail information including Time, Date, PUID, Contact Address, From and To header information, etc.
4. Media Stream Quality Statistics
   1. Connection Packet Loss – data obtained from RTCP sender and receiver reports received from the two video sharing client endpoints
   2. Jitter and Delay Statistics – data from RTCP sender and receiver reports received from the two video sharing client endpoints

• Capability Exchange caching and optimization
• Support for non-3G device endpoints such as a Web Portal, thereby making it possible to conduct a real time Video Share session with a PC user using a web browser.
• Ability to record and store the streamed video on a network based Video Share Storage.
• Redirection of Video Share session to different endpoints based on configured service policies.

4. Service Description

The basic steps involved in setting up and tearing down a Video Share session are as follows:

• Circuit Switch Call Setup
• Capability Query
• Invitation Procedure
• Video Transmission
• Teardown of Video Session
• Teardown of Circuit Switch Call

The Video Share session begins with Circuit Switch call between User A and User B. The next step is the Capability Exchange in which the other handset is queried to determine if the recipient is capable of supporting a Video Share session. This is performed with the SIP OPTIONS method. Both handsets can perform this capability exchange. The Video Share session is initiated by sending a SIP INVITE message to the called party. https://handwiki.org/wiki/index.php?curid=1672930

After the Video Share session has been set up, transmission of the actual video can begin. Video is sent between Video Share clients using RTP (Real-Time Transport Protocol), which is widely used in internet and mobile communities for video streaming. The video transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery using RTCP RR (Receiver Report) and RTCP SR (Sender Report) packets. When either party decides to stop the Video Share session, the session will be torn down (using RTCP BYE) and the SIP session stopped (using SIP BYE). After these steps the Circuit Switch voice call session still exists.

In the case of a Web Portal-based Video Share session, the video is streamed to the Portal instead of User B, and accessed using a PC with a web browser.

5. Deployment Options

There are multiple options for deploying the Video Share service.

• Option 1: The solution is deployed in the mobile operator’s IMS network. The Application Server is integrated into the operator’s IMS Core network. Video Share clients are pre-loaded on selected handsets by the operator. Users sign up for the service through the operator.
• Option 2: The solution is deployed as a hosted service by a third party, independent of the mobile operator. Users download the Video Share client from the third party using a well established handset application download procedure, and sign up for the service with the third party.