As a minimum, it will be useful if mobiles can indicate whether they are using UMTS for their ongoing voice call. However additional functionality would be useful, specifically:

• when using UTRAN, an indication of whether 64 kbit/s video can be supported in the mobile's current location;
• when using GERAN, an indication of whether UMTS coverage is available, and, ideally whether the UMTS coverage can support 64 kbit/s video.

The successful case of the "radio degradation at UE 2 leading to fallback to voice" for UMTS is illustrated in Figure 2.

The procedure in 4.3.1.1 can also be used if UE 2 drops out of UTRAN coverage into GERAN coverage. However there are additional complications:

1. If the UTRAN and GERAN cells are attached to different MSCs then problems are likely to occur due to the time required for the UE 2 to perform Location Area and Routeing Area updating.
   In particular, if UE 2 is updating with a new MSC and/or new SGSN, UE 2 will not respond to MSC 2's paging. This will only become known to UE 1 when MSC 2's "no response to paging" timer expires. Typically, an operator configures this timer with values in the range of 8 to 25 seconds. When this timer expires, it is quite likely that UE 2 will have "call forward on not reachable" set and so UE 1's call will be diverted to a voice mail server. To avoid these problems, it seems important that the operator configures the UTRAN to minimise the number of video calls that lead to fallback to GERAN coverage and/or to configure the network such that geographically similar UTRAN and GERAN cells are in the same Routeing Area.
2. In order to avoid useless handover attempts, the RNCs are frequently configured so that no GERAN neighbour cells are given to the mobile during a video call. This will slow down re-selection from 3G to 2G in the case of total loss of 3G coverage. Conversely, in many other scenarios the lack of 2G neighbour cells might force UE 2 to camp on the 3G cell for long enough for it to receive the paging for the voice call.
   Overall, the operator may need to adapt the neighbour cell lists provided in video calls on cell by cell basis and/or dependent upon whether or not combined 2G/3G MSCs AND combined SGSNs are in use.

Additional study may be beneficial on how to 'synchronise' the release of the RRC connection in the RNC and in the mobile when the radio connection is degraded or lost. If synchronisation cannot be guaranteed then timers may be needed to delay the redial attempt by the A party.

If a redial attempt is unsuccessful, it may (or may not) be appropriate to avoid being forwarded to a voice mail server. One potential solution to this is that the A party signals (e.g. by appending a suffix to the dialled digits) to MSC-A and MSC-A then uses the Call Diversion Not Allowed setting in the Call Diversion Treatment Indicators to inhibit call forwarding. One problem with the use of a suffix in the dialled digits is that the digit analysis in MSC-A usually only examines the leading digits. Conversely, if the UE adds a prefix to the dialled digits, then the call will not be handled properly if MSC-A does not support this functionality.

There are many reasons (User Determined User Busy, Barring of all incoming calls, an existing active video call) why a video call and a re-dialled voice call might both be unsuccessful. It would be useful if the rejection for the video call carried information that helped UE A to determine whether or not a subsequent voice call might succeed.

Can users of video phones be provided with a full suite of supplementary services, e.g. can automatic forwarding to a video mail box when not in UMTS coverage be performed? Analysis of the current Call Forwarding specifications (TS 22.082, TS 23.082) shows that MSC B should reject the call rather than forward it (because the UE is reachable but is not busy and has not been offered the chance to reply). Once a video call has been stored by the mailbox, it can only be retrieved from the mailbox when the UE is in coverage that allows for a 64kbit/s bearer. As long as the UE is not in such a coverage area it cannot receive the video call from the mailbox. One potential solution to this is that the mailbox provides a voice call comprising only the audio part of the video call. An alternative is that the user deactivates all call forwarding for video calls (c.f. CS data calls).