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 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 http://www.gsmworld.com/documents/services/se41.pdf Video Share Definition 2.0, GSMA Document, 27 March 2007 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.
AT&T (formerly Cingular) is one of mobile operators who have deployed the Video Share service nationwide.
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 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.http://www.gsmworld.com/news/press_2006/press06_18.shtml GSMA Press Release on video share trials, 15 February 2006 Video Share was also tested on the IPX http://www.gsmworld.com/sip/sip_trial_guide.pdf The GSMA's SIP Trials, February 2007 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 http://www.wireless.att.com/learn/messaging-internet/media-entertainment/video-share-faqs.jsp AT&T FAQ for Video Share based on the Phase 1 service definition. An interoperability technical reference specification for Video Share http://www.gsmworld.com/documents/ir7412.pdf IR.74 Video Share Interoperability Specification 1.2, GSMA Document, September 2008 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.
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 (e.g., 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
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