GSM Association Official Document SE.41

GSM Association
UNRESTRICTED
Official Document SE.41
Video Share Service Definition

2.0
27 March 2007
This is a non-binding permanent reference document of the GSM Association.
Security Classification Category (see next page)

Not Restricted
GSM Association
UNRESTRICTED
Security Classification - UNRESTRICTED

Access to and distribution of this document is restricted to the persons listed under
the heading Security Classification Category. This document is confidential to the
Association and is subject to copyright protection. This document is to be used only
for the purposes for which it has been supplied and information contained in it must
not be disclosed or in any other way made available, in whole or in part, to persons
other than those listed under Security Classification Category without the prior
written approval of the Association. The GSM Association (“Association”) makes no
representation, warranty or undertaking (express or implied) with respect to and
does not accept any responsibility for, and hereby disclaims liability for the accuracy
or completeness or timeliness of the information contained in this document. The
information contained in this document may be subject to change without prior
notice.
Copyright Notice
Copyright © 2007 GSM Association
GSM™ and the GSM Logo™ are registered and the property of the GSM
Association.
Document History
Versio Date Brief Description

n
0.3 31 July 2006 Completed drafting phase – signoff by PM
0.9 1 August 2006 Prepared for submission to SRG, DAG and EMC
0.95-1 17 August2006 Including SRG comments from Seattle Meeting
1.0 21 August 2006 DAG Comments now included
1.1 22 November 2006 Re-draft to synchronise between the SIP Trial
Video Share Specification 2.3 (IREG DOC)
1.11 27 November 2006 Final cosmetic changes
2.0 27 March 2007 Changes in accordance to CR001
Changes Since Last Version
Other Information
Type Description
Document Owner SRG
Revision Control Annual
Document editor/company M. Hogan/GSMA
Feedback
This document is intended for use by the members of GSMA. It is our intention to
provide a quality product for your use. If you find any errors or omissions, please
contact us with your comments. You may notify us at mailto:prd@gsm.org. Your
comments or suggestions are always welcome.
UNRESTRICTED Version 2.0 Page 2 of 28

GSM Association
UNRESTRICTED
Table of Contents
1 FOREWORD....................................................................................................... 5
2 BACKGROUND ................................................................................................. 5
3 OVERVIEW OF THE SERVICE ...................................................................... 6
3.1 Introduction......................................................................................................................... 6
3.2 Project Information ............................................................................................................ 7
3.3 Service Scope and Assumptions made ......................................................................... 7
3.4 High-level Service Concept.............................................................................................. 8
4 SERVICE DESCRIPTION ................................................................................ 9
4.1 Technical Service Description ......................................................................................... 9
4.1.1 Call Setup............................................................................................................ 9
4.1.2 Capability Query............................................................................................... 10
4.1.3 Session Setup/Invitation Procedure.............................................................. 10
4.1.4 Video Transmission ......................................................................................... 11
4.1.5 Teardown of Video Session ........................................................................... 12
4.1.6 Teardown of CS Call ....................................................................................... 13
4.2 Functional Service Description / Use Cases ............................................................... 14
4.2.1 Use Case 1: Basic Video Share .................................................................... 15
4.2.2 Use Case 2: Sharing Recorded Video.......................................................... 16
4.2.3 Use Case 3: Record Received Video ........................................................... 17
4.2.4 Use Case 4: Multiple Video Share Sessions within a Single CS Call ..... 18
4.2.5 Use Case 5: Recipient Roaming ................................................................... 18
4.2.6 Use Case 6: Sender and Recipient Roaming.............................................. 20
4.3 Service Interworking........................................................................................................ 20
4.3.1 Scope ................................................................................................................. 20
4.3.2 Interworking Scenarios.................................................................................... 20
4.3.2.1 Interworking Scenario 1: User A shares video with User B on
different networks......................................................................................................21
4.3.2.2 Interworking Scenario 2: Record and share on different networks. ..21
4.3.2.3 Interworking Scenario 3: Multiple Video-Share sessions on different
networks......................................................................................................................22
4.3.3 Roaming ............................................................................................................ 23
4.3.4 Interworking Transactions and Charging Principles ................................... 23
4.3.4.1 General Commercial Principles ..............................................................23
4.3.5 Interworking Charging Principles Recommendations ................................ 24
4.4 Usability Studies .............................................................................................................. 24
5 SERVICE REQUIREMENTS AND ENABLERS......................................... 24
5.1 Goals/Requirements ....................................................................................................... 24
5.2 Enablers ............................................................................................................................ 25
5.3 Service and Application Inter-dependencies............................................................... 25
6 DEVICE REQUIREMENTS ............................................................................ 25
6.1 Recommendations for Functional Requirements ....................................................... 26

GSM Association
UNRESTRICTED
6.1.1 Usability ............................................................................................................. 26

6.1.2 Codecs............................................................................................................... 26
7 SYSTEM REQUIREMENTS SPECIFICATIONS........................................ 26
8 OTHER CONSIDERATIONS ......................................................................... 27
8.1 International Lawful Interception and Privacy ............................................................. 27
8.2 Security Review of Service Requirements .................................................................. 27
8.3 Fraud Considerations and requirements ..................................................................... 27
9 GAP ANALYSIS TO EXISTING STANDARDS.......................................... 27

GSM Association
UNRESTRICTED
1 FOREWORD
This document outlines the Service Definition for Video Share .It focuses on
commercial and functional interworking aspects only.
It is to be to be read in conjunction with the Video Share Interoperability

Specification, (IR. 74) which provides technical information regarding terminal
implementation and interoperability.
The intended audience of this document is the GSMA Working Groups and mobile
operators intending to deploy Video Share.
2 BACKGROUND
Video Share is a peer-to-peer service using the IMS infrastructure to allow subscribers to
stream real time video to one another while engaged in a circuit switched (CS) voice call.
This service builds upon existing, non-standard Video Share implementations and trial
implementations done for testing SIP interoperability. The goal of the service is to provide a
common framework for a service that is interoperable among mobile operators.
This Service Definition document in conjunction with the Video Share Interoperability
Specification IR.74 describes the Video Share service concept in sufficient detail to enable
the various GSMA expert groups to provide necessary support to the project.
This Service Definition document will be reviewed and approved by SRG to ensure the
Video Service is in line with the Services Review Group 8 Principles:
• Common solution across operators

• Clear operator role to provide added value
• Inter-operator charging principles
• Appropriate customer charging model
• End-2-End service
• Third party management
• Open access option
• Secure and trustworthy services
The Service Definition document will be reviewed by the Working Groups responsible for
Interoperability and Interworking, to identify what if any changes are to be made to their
PRDs to ensure commercial interoperability (BARG- BA.27 & 12, AA.12-14; IWG- BA.27;
IREG- IR.21; TADIG- TD.57)
The Service Definition will be reviewed by Working Groups responsible for Fraud and
Security to identify any possible security and fraud issues and resolve them.
The Service Definition will be reviewed by Working Groups responsible for Devices (DG,
SCaG) to identify and estimate any impact on devices or SIM cards.

GSM Association
UNRESTRICTED
3 OVERVIEW OF THE SERVICE

3.1 Introduction
Video Share allows an enrichment of an already established voice call by allowing a user to
capture and stream video (either live or pre-recorded) to another user in near real time.
Video Share is distinct from Video Telephony in that it does not incorporate synchronized
audio and is therefore less technically complex to implement. It can, however, be considered
a stepping stone to future deployment of full-duplex video telephony. Alone, it allows users
to extend their communication experience into the visual domain and provides mobile
network operators an opportunity to create new revenue-generating services.
Video Share has the potential to increase Average Revenue per Unit (ARPU) in two ways.
First, the Video Share service can be chargeable; and second, adds the ability to share near
real time video on top of a voice call creates an incentive for users to place voice/video calls
where they might otherwise not.
A measure of the perceived value of Video Share is that several handset vendors currently
have developmental products that do Video Share, and some operators are planning
proprietary deployments of Video Share working within their networks. Other operators have
already launched commercial Video Share services. Presently, at least three specifications
for Video Share exist.
To realise its full revenue-generating potential, however, it is imperative that proprietary

methods be made to interoperate. Subscribers typically will not adopt a new service if they
have to concern themselves with whether or not the called party will be able to receive the
service. Providing a level of standardization sufficient to ensure interworking between GSM
operators and interoperability with different handsets makes the service available to more
subscribers and makes it easy to use. The required standardization involves SIP and video
protocols, codecs, and functional partitioning. The latter refers to the distribution of functions
within the SIP/Video Share architecture (whether it is handled by the device or by proxy
entities in the network), such as trans-coding, addressing, capability query, and others.
The Video Share service will use the standardized IMS Core infrastructure to transmit the
signalling 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.
The Video Share project builds on the technical work done within the GSMA SIP Trials,
where a basic interoperable peer-to-peer Video Share capability was successfully defined,
implemented and demonstrated during 1Q/06 in a multi-vendor, multi-operator environment
composed of seven terminal vendors, 13 3GSM operators and eight GRX carriers. Roaming
between GSM operators was not addressed in the SIP trials and is an essential element to
providing a truly valuable service.
By standardising the service to the extent that subscribers have a common expectation of
how to call up and use Video Share, the likelihood increases that subscribers will remember
to use the service.

GSM Association
UNRESTRICTED
Video Share is a new and evolving service so its capabilities and impact on networks are not
yet fully defined. This Service Definition focuses on Video Share as opposed to other Share
services such as Image Share and File Share. The project will take a two-phased approach,
with the first phase concerned with establishing a common service framework for the basic
form of video share that was demonstrated in the SIP trials and which is technically feasible
today.
The next phase addresses the more advanced features which current implementations do
not support, such as:
• incorporation of presence awareness
• video share in the absence of a circuit switched call
• point-to-multipoint video share
• and other enhancements yet to be determined
This service will likely be targeted at all market segments and include various charging
models, such as pay-per-use, pre-pay, and subscription-based. Operators may deploy this
service to enhance 3G sign-up rates, to drive voice-call revenue or to add to bottom line
revenue figures as a service in its own right.
3.2 Project Information
Reference: Project 127, Toll Gate 1 V1.0, approved May 19 2006

Project Sponsor: Tom Keathley Cingular Wireless
Project Leader: David Smith, Cingular Wireless
Project Manager: Adam Collier GSM Association
Supporting Companies: Orange France, TIM, Cingular Wireless, TMN,
TeliaSonera, Rogers Wireless, Hong Kong CSL, 3 UK
3.3 Service Scope and Assumptions made
As stated in the Introduction, the Video Share project will be accomplished in two phases to
decrease time to market and improve the chances for success.
The Phase 1 service is uni-directional, allowing one user to stream either real-time or pre-
recorded video to another user while on a voice call. Mobile devices can either be traditional
handheld devices or PC-based clients in 3G-enabled laptops. Video Share does not allow
video calling, meaning that neither bidirectional video streaming nor synchronized
audio/video will be supported.
The Video Share service in Phase 1 requires an underlying circuit-switched voice call and
the Video Share session can only be opened between the two parties to the voice call.
During a single voice call multiple (sequential) Video Share sessions can be established,
initiated by either party. Advanced circuit-switched call features, such as call forwarding,
conferencing, call hold, and others., will not apply to Video Share (such as, Video Share will
not be supported on a forwarded CS call for example). Packetised audio will not be
supported for Phase 1.
Video Share service capabilities will be expanded for Phase 2. Definition of the scope for
Phase 2 is one of the deliverables of the Phase 1 work, but under consideration are the
following:

GSM Association
UNRESTRICTED
• Incorporation of presence so that Users will be presented with

something like a ‘buddy list’ showing which of their contacts is
available to receive video
• Point-to-multipoint video share such that one User can stream video
to multiple recipients
• The ability for the Video Share to be paused and resumed
• Standalone PS video share which does not rely on an underlying CS
voice call
• Use of EDGE (unless SIP trials show EDGE to be not viable)
• Incorporation of QoS
• Non-mobile terminals (example: PC clients in ADSL or WLAN
networks)
• Streaming of DRM protected content
3.4 High-level Service Concept
Video Share is a peer-to-peer service using a 3GPP-compliant IMS core system to transmit
packetised video. The Video Share session is set up using SIP and video is transferred
using RTP. The service is intended to be interoperable between GSM operators worldwide
having different IMS core systems and between users with different 3G devices. The
following diagram shows the high level concept:
Figure 1: High-Level Figure of Video Share Connection (IPX Optional)
To create a service Users will feel compelled to use, a Video Share service has to function
with a minimum of set-up or provisioning activity on the User’s part and must support
roaming-in and roaming-out.
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. If available, the receiving handset has to
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.

GSM Association
UNRESTRICTED
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. By providing this feedback to users it is hoped they will be
more tolerant of service malfunctions and will be less likely to become discouraged when the
service fails, which will happen in the early days of deployment.
Network-based servers are not required in Phase 1 Video Share, as this is a peer-to-peer
service. However, in Phase 2 the possible additions of one-to-many sessions and Presence
could require some kind of server side support.
For further technical details of vendor independent Video Share service as specified and
tested in SIP Trial activities, please see GSMA SIP Trial document “Video Share Definition”.
4 SERVICE DESCRIPTION
4.1 Technical Service Description
The basic steps involved in setting up and tearing down a Video Share session are as
follows:
• CS Call Setup
• Capability Query
• Invitation Procedure
• Video Transmission
• Teardown of Video Session
• Teardown of CS Call
These steps are illustrated in more detail in this section which shows the general process
flow used for Video Share. Note that figures are simplified for clarity reasons; for instance,
network elements between User Equipment (UE) are not shown.
Because Video Share uses the IMS infrastructure, both users must be registered with an
active PDP context before sharing can occur. There are two options for handling the SIP
Registration: "Always On" and "On Demand". The “Always On” mode means that a user
establishes SIP registration at device ‘power on’ and remains registered all the time. “On
Demand” implies the user establishes a PDP context only when engaging in an IMS-based
service.
The “Always On” mode ensures that users are registered with the SIP Registrar when they
are in network coverage and ready for VS service at any time. If an operator chooses to
implement “On Demand” registration it must be done in such a way that both parties have an
active PDP context and are ready for a VS service during a circuit switch call. This implies
that SIP registration creation before the Video Share Session formation.
4.1.1 Call Setup

GSM Association
UNRESTRICTED
The Video Share session begins with Circuit Switch call between User A and User B.
4.1.2 Capability Query
At any time during the Circuit Switched call either party can initiate a VS session; it’s
recommended that the next step is the Capability Query in which the other terminal is
queried to determine if the recipient is capable of supporting a Video Share session. This is
performed with the SIP OPTIONS method. Both UEs can perform this query,
Important: As defined in the Videa Share Interoperability Specification (IR.74) replying to a

capability query is mandatory.
Call Setup Capability Query
Figure 2: Capability Query in Video Share
The results of the capability query are indicated to the sending terminal using icons showing
if the intended recipient’s device is VS capable. To minimise network traffic, capability
caching may be deployed so that UEs can forego capability query if not needed. The
caching of the capability query is optional and is handset dependant.
4.1.3 Session Setup/Invitation Procedure
SIP session setup for Video Share is performed following the Capability Query, using either
the IETF mode or IMS mode of SIP signalling. Signal flow for each is shown in the following
figures:

GSM Association
UNRESTRICTED
UE-A UE-B
CS-Voice
Capability Query Procedure
INVITE (request-uri: TEL-URI or SIP-URI)
100 Trying
180 Ringing
200 OK
ACK
Figure 3: Session setup in IETF mode
Figure 4: Session Setup in 3GPP mode
4.1.4 Video Transmission

GSM Association
UNRESTRICTED
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.
Call Setup
Capability Invitation
Query Procedure
Transmission
Video
Figure 5: Video Transmission
4.1.5 Teardown of Video Session
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 CS
voice call session still exists.

GSM Association
UNRESTRICTED
Figure 6: Teardown Video Session
4.1.6 Teardown of CS Call
If users also want to terminate the CS voice call, normal procedures for CS call disconnect
apply.
After CS call has been torn down, we assume here for Phase 1 that the PDP context will be
deactivated if terminal is using PDP Per Call mode. In Phase 2 we may consider the case
where the PS session remains after termination of the CS call. In case Always-on is used,
PDP context will remain after CS call has been terminated

GSM Association
UNRESTRICTED
UE-A UE-B
Call Setup
CS-Voice
Capability Invitation
Query

Procedure
Invitation Procedure
Transmis
Video
Video Transmission
sion
Teardown
Session
Video
Teardown Video Transmission
24.008 DISCONNECT
of CS Call
Teardown
24.008 RELEASE
24.008 RELEASE COMPLETE
Figure 7: Teardown voice (CS) session
4.2 Functional Service Description / Use Cases

Use cases for the Phase 1 Video Share service are shown in the tables below. Some
general comments are noted as follows:
Roaming:
Video Share is intended to function in conventional roaming scenarios, and be charged
accordingly. Conventional roaming scenarios include calling or called party roaming, or both.
In these cases:
• The CS call should be charged as per normal operator roaming
agreements.
• The PS service should be charged per normal operator roaming
agreements..
• The CS and PS sessions should be treated separately
Graceful Failure:
The Video Share service is nominally available to subscribers within a 3G RAN only, which
means a process for handling failures associated with one party transitioning into a 2G RAN
must be addressed.
A particular issue that needs to be addressed is how a session is terminated if both users
move into no-coverage areas during a video session (such as, if the session cannot be
properly terminated there may be problems with correctly charging for the service)
Quality of Service:

GSM Association
UNRESTRICTED
This is not addressed for Phase 1
4.2.1 Use Case 1: Basic Video Share
Use Case Name User A shares video with User B on same/different networks
I want to Share real time video with User B on the same/different networks
ID Number VS1
Both devices are provisioned with Video Share clients (the provisioning can
be done before the launch of the handset by the operator, without requiring
any interaction by the user)
Both users have VS service subscriptions & access credentials (example:
Preconditions
ISIM)
Operator has 3G network deployed and both users are within 3G RAN
Note: Video Share within EDGE RAN is currently out of scope for Phase 1
Operator has IMS core infrastructure
User A and User B are engaged in a CS voice call, initiated by either one.
User A wishes to share video with User B and activates the VS client in
his/her handset. A Capability Query is then performed between the two
devices
User A’s handset shows User B is capable of receiving video.

User A selects “share video” on his/her device User B receives an invitation
that User A wishes to transmit video.
User B selects “accept video share”.
Use Case Narrative
User A receives an indication that User B has accepted the video share
invitation.
User A then captures video with his/her device camera which is streamed in
real time to User B.
Note: In this Use Case it is assumed audio is not streamed via PS link.
User A’s device screen shows the video being sent to User B.
The CS voice call is still active.
Either User A or User B can terminate the video stream and both devices
then indicate that the streaming session has been terminated.

GSM Association
UNRESTRICTED
Use Case Name User A shares video with User B on same/different networks
User B rejects video stream invitation from User A: User A receives an
indication that VS invitation not accepted
User B ignores video stream invitation from User A: User A receives an
indication that VS invitation not accepted
User A moves out of 3G coverage during streaming: User A’s device displays
an indication that video streaming has been interrupted due to coverage loss.
User B receives an indication that streaming was interrupted at the source.
User B moves out of 3G coverage during streaming: User A receives an
indication that video streaming has been terminated at the receiving end.
User B’s device indicates that video streaming has been terminated due to
Exceptions
coverage loss.
User A’s handset fails (or battery dies): User B receives an indication that
video streaming terminated at source OR loss of CS call serves as indication
to User B that source has failed.
User B’s handset fails (or battery dies): User A receives indication that video
streaming terminated at receiving end OR loss of CS call serves as indication
to User A that reception has failed.
User B’s handset is not capable of receiving User A’s video stream: Prior to
streaming video, User A’s handset will indicate (example: via greyed-out icon)
that User B cannot receive video.
Video Share setup time is < 2 sec (setup time is a guideline only)
KPIs Setup time is time from User A INVITE to SIP 200 OK and User A ACK
CS vs. PS differential latency is < 2 sec
User A’s device must have a camera capable of capturing video.

User A’s and User B’s devices must use same video codecs, or network must
employ transcoding
Constraints Network must collect “call” records such that video session may be charged
appropriately
Both tel URI and SIP URI addressing schemes can be used. (note: tel URI
addressing assumes ENUM capability)
Audio is sent only via CS link and not via PS. If differential latency between
CS and PS is sufficiently low synchronization between the CS audio and PS
video may provide an acceptable subjective user experience, although this is
Technical Comments
beyond the scope of the VS project. Call records and charging infrastructure
must be able to accommodate correct charging in the event video link is lost
prior to proper termination.
4.2.2 Use Case 2: Sharing Recorded Video
Use Case Name Record and Share on same/different network

I want to Record video and stream at a later time to User B

GSM Association
UNRESTRICTED
Use Case Name Record and Share on same/different network
ID Number VS2
Same as Use Case VS1, and additionally:
Preconditions
User A’s device has capability to store ‘n’ seconds of captured video
User A wishes to capture video to share with User B and cannot wait for User
B to accept the stream before starting the video capture.
User A records the video to his/her device for later streaming to User B.
Use Case Narrative
At a later time, User A sets up a Video Share session as in Use Case VS1,
except that rather than sending real-time video, the pre-recorded video is
streamed to User B.
Exceptions Same as Use Case VS1
KPIs Same as Use Case VS1
Constraints Same as Use Case VS1
This Use Case could increase the cost of User A’s handset due to the
memory required to store captured video. The ability to record and share
video is therefore recommended to be an optional feature.
Technical Comments
The sharing of recorded video is a handset implementation option, and is not
included in the Video Share Interoperability Specification, (IR.74).
4.2.3 Use Case 3: Record Received Video
User B Records received video stream on same/different

Use Case Name
network.
I want to Send real time video to User B, which User B then records.
ID Number VS3
Same as VS1 and additionally:
Preconditions
User B’s handset has memory capacity to record streamed video
User A wishes to stream real time video to User B.
User A would like to have the video recorded but lacks the capability
Use Case Narrative
(example: memory) to record the captured video.
User A sets up a VS session with User B as per Use Case VS1 and verbally

GSM Association
UNRESTRICTED
User B Records received video stream on same/different

Use Case Name
network.
requests (via the CS audio link) User B to record the received video.
User B’s device has the capability and sufficient memory to store the video
streamed from User A. User B selects “record video” and as the video is
streamed from User A to User B, User B’s device displays the streamed
video and simultaneously records it.
When/if User B’s handset memory becomes full; an indication of such is
presented to User B. The session ends as per Use Case VS1.
Exceptions Same as VS1
KPIs Same as VS1
Same as VS1 and additionally:
Constraints Video stream must be generated by User A’s camera and not be subject to
Digital Rights Management restrictions.
The recording of shared video is a handset implementation option, and is not
Technical Comments included in the Video Share Interoperability Specification, (IR.74).
4.2.4 Use Case 4: Multiple Video Share Sessions within a Single CS Call
Use Case Name Multiple Video Share Sessions on same/different network

Start and stop multiple sequential video share sessions with User B during a
I want to
single CS voice call
ID Number VS4
Preconditions Same as Use Case VS1
User A invokes multiple video share sessions during one CS call by
Use Case Narrative
terminating and restarting the VS session.
Exceptions Same as Use Case VS1
KPIs Same as Use Case VS1
Constraints Same as Use Case VS1
Every effort should be made to ensure that the time required to setup multiple
VS sessions is kept to a minimum. Example: A user friendly handset with
options to send additional streams after the initial stream has been
Technical Comments terminated.
IMS Infrastructure needs to be able to discern and account for the multiple
video streaming sessions during the CS call.
4.2.5 Use Case 5: Recipient Roaming
Use Case Name User B on roamed network.

I want to Share video with User B who is roaming.

GSM Association
UNRESTRICTED
Use Case Name User B on roamed network.

ID Number VS5
Both devices are provisioned with Video Share clients

Both users have VS service subscriptions & access credentials (Example:
Preconditions ISIM)
Both operators have IMS core infrastructures
Same as Use Case VS1 except that User B is roaming. If roamers incur
Use Case Narrative terminating charges, User B should be informed during the INVITE procedure
that charges may apply.
KPIs Same as VS1
Constraints Same as VS1
Technical Comments

GSM Association
UNRESTRICTED
4.2.6 Use Case 6: Sender and Recipient Roaming
Use Case Name Users A and B on roamed networks
I want to Share video with User B who is roaming while I am roaming.
ID Number VS6
Both devices are provisioned with Video Share clients
Both users have VS service subscriptions & access credentials (Example:
Preconditions ISIM)
All operators have IMS core infrastructures
Same as Use Case VS1 except both Users A and B are roaming. If roamers
Use Case Narrative incur terminating charges, User B should be informed during the INVITE
procedure that charges may apply.

KPIs Same as VS1
Constraints Same as VS1
Technical Comments
4.3 Service Interworking

4.3.1 Scope
Interoperability is a critical factor to the success of Video Share as it will drive adoption by
subscribers. As this service will involve more than one operator, this section will describe the
associated scenarios which clarify the interworking relationships, and in particular we will
recommend control points and charging principles.
4.3.2 Interworking Scenarios
In the following table we highlight which of the use cases from the previous section require
interworking between operators:
Case
Description Requires interworking
Number
User A shares video with User B on
Use Case 1 Yes, when on different networks
same/different networks
Use Case 2 Record and Share on same/different Network Yes, when on different networks
Yes but this scenario is identical to

User B Records Received Video Stream on
Use Case 3 use case 1 in terms of
same/different Network.
interworking.
Multiple Video Share Sessions on
Use Case 4 Yes, when on different networks
same/different Network

GSM Association
UNRESTRICTED
Case
Description Requires interworking
Number
Use Case 5 User B on Roamed Network. No, see 3.3.3
Use Case 6 Users A and B on Roamed Networks No, see 3.3.3.
Therefore, we must analyze three use cases for interworking purposes.
The following diagrams show the process flow when two operators are involved in a
direct (bi-lateral) agreement. The elements of the data session that will generate
periodic events are illustrated in bold and red. If an IPX model is used, the same
events will be generated by the operator’s IMS infrastructure but will be passed to
the IPX rather than directly to the receiving operator. The IPX will then have to settle
with MNO-A and MNO-B.
4.3.2.1 Interworking Scenario 1: User A shares video with User B on different networks.
4.3.2.2 Interworking Scenario 2: Record and share on different networks.

This scenario is similar to the previous scenario, the only difference being that the video has
been pre-recorded and is therefore not streamed in real-time from User A’s camera.

GSM Association
UNRESTRICTED
4.3.2.3 Interworking Scenario 3: Multiple Video-Share sessions on different networks

GSM Association
UNRESTRICTED
MNO-A MNO-B
UE-A IMS Infrastructure IMS Infrastructure UE-B
CS-Voice
User B Invitation to Share Video

appears
as “VS Invitation to Share Video
capable”
Invitation to Share Video
“Accept” Video Share
Interworking
events generated
User A begins capturing by MNO-A’s IMS
video through camera infrastructure at
regular intervals
Real-time
stream of video Real-time
User A stream of video Real-time
can see EDR stream of video
that VS is
being EDR
sent EDR
Stop video share
Stop video share
Stop video share
CS-Voice session continues

...

Real-time
EDR stream of video
EDR
EDR
Stop video share

Stop video share
Stop video share
CS-Voice session continues
4.3.3 Roaming
Recommendations for roaming are as follows:
• Users should not incur SIP signalling charges when roaming
• Roamed VS session will generate an additional data charge to the
roaming party (be they the sending or receiving party).
4.3.4 Interworking Transactions and Charging Principles
Note: All recommendations do reflect the charging principles and do not reflect any
recommendation with regard to the price-level on inter-working. Despite the
recommendations given below, Operators can decide in bi-lateral agreements to, as an
example, not apply charges for certain service enablers on inter-working.
4.3.4.1 General Commercial Principles
• Inter-working is not free; this aligns with IP Inter-working strategic
initiative
• Initiating Party Pays (IPP)
• Calling Party Pays (CPP), for the CS call
• Signalling and SIP Setup will not be charged
• For the enablers (presence & contact list management) – Phase 2
GSM Association
UNRESTRICTED
These transactions may be free of charge as far as viable to promote service and
drive traffic
All events with inter-working impact are defined and charging principles are
proposed to every single event to allow inter-working charging if it is required by
Operators after first service take off. It is recommended by the project to monitor the
traffic caused by service enablers and to react accordingly, as an example in the
case of un-balanced traffic
4.3.5 Interworking Charging Principles Recommendations
Interworking charging bases for Packet Switched, Video Share may include:
• Time based (per minute)

• Event Based (such as, per session)
• Volume
No additional charges specific to Video Share except the ones linked to the volume
exchanged should apply
Video Share charging will be separate from CS voice call charging.
The assumed model for VS charging is initiating party pays (note that we mean the party that
initiates the VS session, which may not be the party initiating the CS call).
Note: Charging will not be incurred if a VS session is rejected by the recipient or by some
network profile for the recipient that causes VS to be automatically rejected.
Advice of Charge is not considered for Phase 1.
4.4 Usability Studies

No Video Share usability studies have been executed by the GSM Association.
5 SERVICE REQUIREMENTS AND ENABLERS

5.1 Goals/Requirements
Note: QoS is not a requirement for Phase 1.
We recommend the following performance goals and requirements for Video Share:
• Latency: Near-real-time (latency < 2 seconds)

• Session set-up time: Less than approx 2 seconds (depends on
whether the user’s IMS registration is in “Always On” or in “On
Demand” mode)
Please refer to the Video Share Interoperability Specification, (IR.74) for further information.

GSM Association
UNRESTRICTED
5.2 Enablers
The Video Share service is envisaged to work in Wideband CDMA networks with IMS core
infrastructure IMS authentication will be assumed, using either the early IMS Security, IMS
AKA using ISIM or USIM, or HTTP Digest.
(3GPP has defined only the Early IMS Solution and the preferred full IMS solution where the
authentication uses Digest-AKA, a combination of AKA and HTTP-Digest. 3GPP did not
allow the use of HTTP-Digest method (without AKA) because this poses a security problem
insofar as the HTTP-Digest password needs to be provisioned by other insecure methods if
AKA is not used to provision it. It can also be argued that allowing HTTP-Digest seems to
contradict the requirement in section 5 to bind the "user subscription ... to their smart card".)
Both PDP Always-On and PDP On Demand modes can be used. If PDP Per-Call mode is
used, SIP registration and PDP activation are performed upon the CS call. Always-on
method decreases the set-up time of Video Share. The shorter the session set-up time, the
better the end-users rate the service.
The GPRS Exchange (GRX) architecture will be used as the interconnect network. The
service is envisaged to be deployed via bilateral interconnect until such time as IPX
becomes available. This service definition and supporting documents are written with
transfer to IPX in mind
For “see-what-I see” functionality the service does not require DRM. Sharing of DRM-
protected video clips may be addressed in Phase 2. DRM is not supported in Phase 1.
The service is based on current billing methods and does not create any additional
requirements for mobile payment methods. There are no Trust Model or Location Awareness
requirements for the Video Share service.
5.3 Service and Application Inter-dependencies

Video Share currently does not depend on other services. Note that interdependencies will
be addressed in Phase 2.
IMS is seen as Infrastructure and not as service interdependency.
6 DEVICE REQUIREMENTS
Authentication and authorization for the Video Share service is implicit in IMS authentication.
Thus it is assumed that VS-compliant devices contain an ISIM/USIM properly provisioned
with public and private identities and access credentials. A user’s subscription has to be
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 device needs to be 3G or EDGE compliant, and in the case of EDGE the device needs
to support DTM.
When a Video Share session is established, the receiving handset has to automatically go to
speakerphone mode (if available) when the video received, unless the recipient’s headset is
in place. When placing a CS call, Video Share will be an option via the phone book just like

GSM Association
UNRESTRICTED
SMS and a soft key can indicate the Video Share capability of potential recipients. The
Video share client should be easy to configure whether by the MNO before launching the
handset, or using OTA solutions.
If capability information is already available, the Video share Icon should be activated. If this
information is not to hand, and depending on the capability query procedure chosen, after
the circuit switch call has been established and the capability determined, the video share
Icon should be activated.
Conversely, if the capability information is available, and one party is not compliant, the
Video Share Icon should be hidden from mobile phone menus.
Note: This could be due to network or handset limitations.
6.1 Recommendations for Functional Requirements

No device support for streaming QoS or secondary PDP context associated with QoS is
required for Phase 1 Video Share
6.1.1 Usability
• Devices shall support privacy policies that allow users to block other
users from performing a Capability Exchange with their device and/or
streaming video to their device.
• Either a transmitting or receiving device shall be able to terminate a
VS session at any point during the session.
• A Video Share session shall be terminated upon termination of the
underlying CS call
• The device shall not present an option to initiate Video Share when it
is on 2G.
• The device shall drop a VS session when the device transitions from
UMTS to GSM during the session and provide the user with a user-
friendly indication of the drop. The CS voice call shall remain
connected.
• Receiving device should provide audio indication of an incoming VS
request, in addition to a visual indication
• Device should go to speakerphone mode upon receipt of video
stream unless a headset is in use
• Transmitting device should display the video that is being streamed
6.1.2 Codecs
Refer to Video Share Interoperability Specification, (IR.74)
7 SYSTEM REQUIREMENTS SPECIFICATIONS

No special SIM/USIM provisioning (Assumes ISIM or derivation of public identity from IMSI).

GSM Association
UNRESTRICTED
From a User perspective when the video share application is available on the device, there
should be no provisioning operation done by the customer. The service should be available
without any specific action.
Infrastructure assumptions are:

• IMS core
• Envisaged to work via bilateral interconnect, bilateral IPX interconnect
and/or multi-lateral IPX interconnect.
• 3G network
• SIP stack/client in phone
8 OTHER CONSIDERATIONS
8.1 International Lawful Interception and Privacy
Lawful interception is already covered as this service uses existing bearer network
connections
As Video Share will operate as though it is a P2P service the network will merely be a carrier
and will not have visibility of the content. It is recommended that Terms and Conditions must
absolve the operator of any liability for any illegal content that is transmitted.
8.2 Security Review of Service Requirements

A/B Number spoofing has been exploited on IMS & SIP based services; implementations of
such services need keep this in mind.
SIP is exposed to call setup packets being used for transmission of additional textual
information such as a simple free SMS style text exchange could be establishes using call
setup packets. However, this is not an issue if the Video Share service will only operate
during a rated voice call.
8.3 Fraud Considerations and requirements

When considering further enhancements to Video Share, the streaming of non-video data
needs to be aware of possible arbitrage issues with other data services.
9 GAP ANALYSIS TO EXISTING STANDARDS

There are currently no existing standards for Video Share as a service by itself. Several (at
least three) known proprietary specifications exist, however. It is the goal of this project to
consolidate these existing specifications toward a common service framework.
The Video Share service will rely on enabling specifications that exist today to provide
signalling and bearer functions, authentication, and others.
It is recognized that interaction with SDOs will be necessary to ensure Video Share devices
and infrastructure elements interoperate. Liaisons with the OMA may, for example, be

GSM Association
UNRESTRICTED
needed to develop application layer specifications to standardize signalling interfaces and

user experience. And since 3GPP ‘owns’ the IMS infrastructure, liaisons with that group may
be necessary if changes to their specifications are indicated by the work performed within
this project.
End of Document

GSM Association Official Document SE.41

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

GSM Association Official Document SE.41

Загружено:

Авторское право:

Доступные форматы

GSM Association

Video Share Service Definition

This is a non-binding permanent reference document of the GSM Association.

Security Classification Category (see next page)

Security Classification - UNRESTRICTED

Versio Date Brief Description

UNRESTRICTED Version 2.0 Page 2 of 28

UNRESTRICTED Version 2.0 Page 3 of 28

6.1.1 Usability ............................................................................................................. 26

UNRESTRICTED Version 2.0 Page 4 of 28

It is to be to be read in conjunction with the Video Share Interoperability

• Common solution across operators

UNRESTRICTED Version 2.0 Page 5 of 28

3 OVERVIEW OF THE SERVICE

To realise its full revenue-generating potential, however, it is imperative that proprietary

UNRESTRICTED Version 2.0 Page 6 of 28

3.2 Project Information

Reference: Project 127, Toll Gate 1 V1.0, approved May 19 2006

UNRESTRICTED Version 2.0 Page 7 of 28

• Incorporation of presence so that Users will be presented with

Figure 1: High-Level Figure of Video Share Connection (IPX Optional)

UNRESTRICTED Version 2.0 Page 8 of 28

UNRESTRICTED Version 2.0 Page 9 of 28

Important: As defined in the Videa Share Interoperability Specification (IR.74) replying to a

Figure 2: Capability Query in Video Share

UNRESTRICTED Version 2.0 Page 10 of 28

Capability Query Procedure

INVITE (request-uri: TEL-URI or SIP-URI)

Figure 3: Session setup in IETF mode

Figure 4: Session Setup in 3GPP mode

4.1.4 Video Transmission

UNRESTRICTED Version 2.0 Page 11 of 28

Figure 5: Video Transmission

4.1.5 Teardown of Video Session

UNRESTRICTED Version 2.0 Page 12 of 28

Figure 6: Teardown Video Session

4.1.6 Teardown of CS Call

UNRESTRICTED Version 2.0 Page 13 of 28

Capability Query Procedure

Teardown Video Transmission

24.008 RELEASE COMPLETE

Figure 7: Teardown voice (CS) session

4.2 Functional Service Description / Use Cases

UNRESTRICTED Version 2.0 Page 14 of 28

This is not addressed for Phase 1

4.2.1 Use Case 1: Basic Video Share

User A’s handset shows User B is capable of receiving video.

UNRESTRICTED Version 2.0 Page 15 of 28

User A’s device must have a camera capable of capturing video.

4.2.2 Use Case 2: Sharing Recorded Video

Use Case Name Record and Share on same/different network

UNRESTRICTED Version 2.0 Page 16 of 28

Use Case Name Record and Share on same/different network

4.2.3 Use Case 3: Record Received Video

User B Records received video stream on same/different

UNRESTRICTED Version 2.0 Page 17 of 28

User B Records received video stream on same/different

Use Case Name Multiple Video Share Sessions on same/different network

4.2.5 Use Case 5: Recipient Roaming

Use Case Name User B on roamed network.

UNRESTRICTED Version 2.0 Page 18 of 28

Use Case Name User B on roamed network.

Both devices are provisioned with Video Share clients