For the purposes of the present document, the following terms and definitions apply. Teleservice: Videotelephony:

For the purposes of the present document, the following abbreviations apply: VT UE Further abbreviations are given in TR 21.905.

ITU-T has specified that Recommendation H.324 should be used for video telephony in circuit switched connection. The 3GPP-variant of H.324 is named 3G-324M and the corresponding 3GPP specification is the TS 26.110 "Codec for circuit switched multimedia telephony service" and TS 26.111 "Modification to H.324". 3G-324M terminals provide real-time video, audio, or data, in any combination over 3GPP circuit-switched radio networks.

The RAB and the corresponding BS30 is not only for video telephony, data transfer is also possible. The user is able to select via terminal, depending on terminal capabilities, which service they prefer, but the CN may not be able to distinguish between video telephony and data transfer unless the UE provides such indication. This also applies to changes during call set-up and in-call modification of the requested service. That means the current charging architecture may not be able to support e.g. two different pricing models for video telephony and data transfer.

The BS30 is a general synchronous bearer service with support of supplementary services. TS 22.004 includes an overview of the supplementary services which are supported and which are not supported by the BS30 bearer as shown in the Table below:

It should be possible for the network to identify when a videotelephony is established so that accurate charging can be realised. All the events related to the videotelephony call such as modifications of the service type (e.g. speech call to videotelephony call modification, fall back to speech), modification of the codecs and so on should be recorded.

It should be possible for terminals to perform codec negotiation during videotelephony call set up. This should result in reduced call set up time for videotelephony calls and may allow new and more efficient video codecs to be introduced easily within mobile networks. This should be realised in the same fashion as speech call where the calling terminal presents to the recipient a list of supported codecs alongside the preferred one.

The user shall be able to use and access the VT service in a secure manner. It shall be possible to deny access to the VT service to unauthorized users. An authorization may be based on the identity of the originating and/or destination user/device. The "Security Threats and Requirements" specified in TS 21.133 shall not be compromised.

It shall be possible to prevent exchange of user's identity during call setup (e.g., by using CLIR/COLR). In addition, to protect user privacy it shall be possible to:

• enable/disable video camera during the call.
• accept a video call in audio mode only.
• enable/disable audio during the call (mute/unmute).

A recipient shall be informed of the identity of the sender in case the sender has not restricted his identity to be transmitted. Optional support for ciphering user audio/video/data sessions should be considered.

At least the following supplementary services should be supported for videotelephony, which are already available for BS30:

• eMLPP (enhanced Multi-Level Precedence and Pre-emption)
• CD (Call Delfection)
• CLIP (Calling Line Identification Presentation)
• CLIR (Calling Line Identification Restriction)
• COLP (Connected Line Identification Presentation)
• COLR (Connected Line Identification Restriction)
• all the call forwarding types (CFU, CFB, CFNRy, CFNRc)
• CW (Call Waiting)
• CUG (Closed User Group)
• AoCI (Advice of Charge Information) and AoCC (Advice of Charge Charging)
• UUS (User-to-user signalling)
• all types of barring (BAOC, BOIC, BOIC -exHC, BIC, BIC-Roam)
• CCBS (Call Completion to Busy Subscriber)
• SPNP (Support of Private Numbering Plan)
• MSP (Multiple Subscriber Profiles)
• MC (Multicall)

Furthermore following supplementary services should be supported:

• HOLD:
• CNAP (calling name presentation)

The support of multiparty is for further study.

When the radio access network of the calling party or of the called party cannot support any longer the video media, or the interconnection between networks does not or no longer support videotelephony, the videotelephony call should be downgraded to a speech call. The transition from videotelephony to speech should be realised with minimum (ideally without) interruptions. When the videotelephony call can be supported again the downgraded call, i.e.the speech call, may be upgraded to a videotelephony call. The transition from speech to videotelephony should be realised with minimum (ideally without) interruptions. The fall back from videotelephony to speech and the upgrade from speech to videotelephony should be supported when requested by either party. The user should be able to deny a service change from speech to videotelephony. It should be possible to accept a videotelephony call with downgrading to speech, which means the user should be able to request a downgrade of an incoming videotelephony call before the call is answered resulting in establishing a speech call only.

It should be possible for the mobile operator to control the access to the videotelephony service by means of a subscription to the service.

Inter-system handover between UMTS and GSM is not supported for 64 kbps UDI calls. In the case of a user moving out of 3G coverage, the video call will be released. The user has to establish a voice call either manually or the handset provides a voice call set up automatically. In the early days of UMTS this is an especially likely scenario. Therefore, the handover from 3G to 2G linked with a downgrade from video to voice is a desirable functionality. Handover of VT between UMTS and I-WLAN should be available if the network is available and if the terminal has this functionality.

The capability of establishing a videotelephony call towards an emergency number should not be mandatory. If a user attempts to establish a videotelephony call to an emergency service, which is not equipped to handle video telephony calls, the UE or the network should be able to transform it to an emergency speech call (TS12) set up request.

A network should provide notifications to the user(s) if needed, e.g., if the call set-up is unsuccessful or modified (e.g., by applying supplementary services). Notifications can consist of audible (e.g. announcement) and / or of visible ( e.g. picture or video) and / or textual information.

Void

Similar to the BS30 multimedia call bearer service the new videotelephony teleservice (if specified) should support interconnection with CS videotelephony services provided by PSTN and ISDN fixed networks.