Video share

Video Share is an IP Multimedia System (IMS) enabled service for mobile networks that allows users engaged in a circuit switch voice call to add a unidirectional video streaming session over the packet network during the voice call. Any of the parties on the voice call can initiate a video streaming session. There can be multiple video streaming sessions during a voice call, and each of these streaming sessions can be initiated by any of the parties on the voice call. The video source can either be the camera on the phone or a pre-recorded video clip.

Video share is initiated from within a voice call. After a voice call is established, either party (calling or called) can start a Video Share (VS) session. The sending User is then able to stream one-way live or recorded video. The default behavior is that the receiving handset will automatically go to speakerphone mode when video is received, unless the headset is in place. The sender will be able to see what is being streamed on their handset, along with the receiving User. In this scenario, the sender can “narrate” over the CS audio connection while both parties view the video. Both users will have the ability initiate a video share session, and either the sender or recipient in a video share session can terminate the session at any time. As part of the VS invitation, the recipient can choose to reject the streamed video. It is intended that both sender and receiver will receive feedback when the other party terminates a session or the link drops due to lack of coverage.

The Video Share service is defined by the [http://www.gsmworld.com/sip/e2e/videoshare.shtml GSM Association] (GSMA). It is often referred to as a Combinational Service, meaning that the service combines a circuit switch voice call with a packet switch multimedia session. This concept is described in the 3rd Generation Partnership Project (3GPP) specification documents 3GPP TS 22.279, 3GPP TS 23.279 and 3GPP TS 24.279. The Video Share service requires a 3GPP compliant IMS core system.

GSM Association has split the Video Share service definition into 2 distinct phases. The first phase (also called Phase 1) involves sharing a simple peer-to-peer, one-way video stream in conjunction with, but not synchronized to a circuit switch voice call. The second phase (also called Phase 2) introduces the Video Share Application Server in the solution and supports more complex features and capabilities, such as point-to-multipoint video share calls, video streaming to a web portal, and integration of video share with instant messaging.

In the industry, Video Share is also referred to by other names such as See What I See and Rich Voice Call.

Video Share is supported only in UMTS and EDGE (with DTM) networks. It is not supported in a GPRS or a CDMA network. The Video Share Client will drop a VS session when the handset transitions from UMTS to GSM during the session. The CS voice call will remain connected.

[http://www.wireless.att.com/learn/messaging-internet/media-entertainment/attvideoshare.jsp AT&T] (formerly Cingular) is one of mobile operators who have deployed the Video Share service nationwide.

History

The Video Share service 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.

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 based on the Phase 1 service definition. [http://www.gsmworld.com/documents/index.shtml PRD IR.74] is the technical reference specification for Video Share.

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

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:
# 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.
# 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 (eg., videophone, webcam).
# 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.

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.

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

Vendors providing Video Share clients based on the GSMA service definition include: [http://www.nokia.com Nokia] , [http://www.motorola.com Motorola] , [http://www.picomobile.net/ PicoMobile (Marvell)] , [http://www.samsung.com Samsung] , [http://www.nmscommunications.com NMS Communications] , [http://www.ecrio.com Ecrio Inc] , [http://www.sonyericsson.com Sony Ericsson] , [http://www.lge.com LG] , [http://www.aylus.com Aylus Networks] , [http://www.comneon.com Comneon GmbH] , [http://www.radvision.com/Products/Developer/Clients/VideoShare/ RADVISION] .

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:
# Session statistics including those established, terminated, initiated, and failed
# User registration statistics including those registered, de-registered, registration rejected
# Active Call Detail information including Time, Date, PUID, Contact Address, From and To header information, etc.
# Media Stream Quality Statistics
## Connection Packet Loss – data obtained from RTCP sender and receiver reports received from the two video sharing client endpoints
## 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.

[http://www.aylus.com Aylus Networks] provides a Video Share Application Server with advanced features and capabilities. [http://www.solaiemes.com Solaiemes] sells a customizable Application Server that can be integrated by 3rd parties in enterprise and vertical markets.

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.

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.

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.

References

* Combining Circuit Switch (CS) and IP Multimedia (IMS) Services, TS 23.279, 3rd Generation Partnership Project
* Combining Circuit Switch (CS) and IP Multimedia (IMS) Services, TS 24.279, 3rd Generation Partnership Project
* Video Share Definition 2.0, GSMA Document, 27 March 2007
* [http://www.gsmworld.com/documents/index.shtml IR.74 Video Share Interoperability Specification]